Re: [PATCH] Also install data-directory into the build directory as computed by relocate_gdb_directory

[Khoo Yit Phang <khooyp@cs.umd.edu>]

Hi,

On Oct 4, 2012, at 11:07 AM, Doug Evans wrote:

> On Thu, Oct 4, 2012 at 7:51 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>>>> 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.
>>> 
>>> How so?
>> 
>> 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...
> 
> 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 presence of other files/directories, and some other application happens to use the same files/directories, then the user is basically stuck with either a non-working gdb (sans -data-directory) or having to uninstall that other application.

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 cover most purposes of running gdb from the build directory, since I don't see 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 gdb will likely have to be installed anyways. Does anyone currently have a use 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 Google) 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 fairly 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 gdb/gdb" to debug gdb which is trivial. There's no need to compile/link another 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 using execv with argv[0] == "gdb-dev").

Yit
October 6, 2012