From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31520 invoked by alias); 22 Feb 2007 15:59:48 -0000 Received: (qmail 31259 invoked by uid 48); 22 Feb 2007 15:58:08 -0000 Date: Thu, 22 Feb 2007 15:59:00 -0000 Message-ID: <20070222155808.31258.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "bfriesen at simple dot dallas dot tx dot us" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-02/txt/msg02570.txt.bz2 ------- Comment #19 from bfriesen at simple dot dallas dot tx dot us 2007-02-22 15:58 ------- (In reply to comment #8) > Note that, on PA, the linker does indeed annotate an executable with the > location in which it found the library, but that's just a cache, it doesn't > require the library to be there in order to function. Libtool knows about that, > and does the right thing when linking with a libtool library, but libgcc_s isn't > a libtool library, so libtool can't do much. It seems to me that on systems which encode the default library search path, this behavior becomes a security weakness associated with the installed library. If the GCC build directory is not secure in that it can't be re-created by another party, then applications searching for libraries in the build tree become subject to trojan horse type attacks. This is particularly the case when GCC is built under /tmp (as some people do) since once the tree has been removed, any other user on the system may create the necessary paths. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291