From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24689 invoked by alias); 6 Oct 2012 19:02:16 -0000 Received: (qmail 24593 invoked by uid 22791); 6 Oct 2012 19:02:15 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from server-nat-6.cs.umd.edu (HELO bacon.cs.umd.edu) (128.8.127.149) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 06 Oct 2012 19:02:08 +0000 Received: from [192.168.2.10] (pool-72-83-72-24.washdc.east.verizon.net [72.83.72.24]) (Authenticated sender: khooyp) by bacon.cs.umd.edu (Postfix) with ESMTPSA id 290A4B40A73; Sat, 6 Oct 2012 15:02:05 -0400 (EDT) Subject: Re: [PATCH] Also install data-directory into the build directory as computed by relocate_gdb_directory Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Khoo Yit Phang In-Reply-To: Date: Sat, 06 Oct 2012 19:02:00 -0000 Cc: Khoo Yit Phang , Joel Brobecker , Jan Kratochvil , GDB Patches Content-Transfer-Encoding: quoted-printable Message-Id: <970CCEFD-FF30-4ED4-9ED9-F9C6A5400120@cs.umd.edu> References: <9F52A338-A158-44DC-90C1-F46503859613@cs.umd.edu> <285502C6-1395-4049-9D55-031EDA3AD06D@cs.umd.edu> <20120924170348.GI4146@adacore.com> <20120927091737.GB2980@adacore.com> <20121004000840.GI3028@adacore.com> <20121004013358.GJ3028@adacore.com> <20121004145105.GP3028@adacore.com> To: Doug Evans X-CSD-MailScanner-ID: 290A4B40A73.AE56E X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: khooyp@cs.umd.edu X-CSD-MailScanner-Watermark: 1350154925.70051@W/IFBqLdVN6krrgXhm0sTQ Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-10/txt/msg00106.txt.bz2 Hi, On Oct 4, 2012, at 11:07 AM, Doug Evans wrote: > On Thu, Oct 4, 2012 at 7:51 AM, Joel Brobecker wr= ote: >>>> I think that this is opening the door for allowing GDB to execute >>>> code without the user being aware of it. I'd rather avoid that. >>>=20 >>> How so? >>=20 >> Let's say: I build a debugger and install it somewhere, and then >> tell my collegues: Hey, use my super-duper GDB. Then, someone hacks >> into my account, set things up to put my GDB into a situation where >> it will think that it's still in a build directory, and then place >> some code in the datadir/python area to auto-execute some malicious >> code... >=20 > If they've hacked into your account seems like it's game over regardless. > [All sorts of nasties could be inflicted - e.g., just hack the gdb > binary directly.] I think the bigger issue is that $BUILDDIR/gdb/data-directory overrides the= standard data-directory. If we detect run-from-builddir based on the prese= nce of other files/directories, and some other application happens to use t= he same files/directories, then the user is basically stuck with either a n= on-working gdb (sans -data-directory) or having to uninstall that other app= lication. I prefer just installing data-directory into $BUILDDIR/share/data-directory= , which is simple and works as long as gdb isn't configured with --bindir, = --exec-prefix, and/or --with-gdb-datadir that are too unusual. It should co= ver most purposes of running gdb from the build directory, since I don't se= e much reason to change --bindir, --exec-prefix, and/or --with-gdb-datadir = if gdb won't be installed, unless for testing those flags, in which case gd= b will likely have to be installed anyways. Does anyone currently have a us= e case I'm missing? I'm okay with Joel's idea of detecting based on the gdb binary name, i.e., = we can link/copy another binary named "gdb-dev" (or something easy to Googl= e) to gdb, and load the build-local data directory when it is run. This can= 't suffer from inadvertent collisions with other applications, and it's fai= rly obvious to users that they are not running the standard gdb since they = have to type it out, and us GDB developers will have to run "gdb/gdb-dev gd= b/gdb" to debug gdb which is trivial. There's no need to compile/link anoth= er program, but there's a small expense of dead code when installed, and a = small risk of a user sym-linking "gdb-dev" to gdb (or making a copy or usin= g execv with argv[0] =3D=3D "gdb-dev"). Yit October 6, 2012