Re: [patch] New set auto-load-local-gdbinit + disable it by default

[Pedro Alves <palves at redhat dot com>]

On 01/17/2012 08:32 PM, Jan Kratochvil wrote:
> On Tue, 17 Jan 2012 21:21:42 +0100, Pedro Alves wrote:
>> Having to request a safe mode with an extra flag is a flawed design, IMO.
>> New, and non-aware-of-the-issues-implied (read, most) users, will just
>> not know about it, and will therefore not use it.
> 
> I agree with it.  I am thinking about it for more days already.  But I have
> not found a way out.
> 
> The problem is to differentiate these two cases:
> (a) as regular user:
> 	$ tar xzf foreign-crash.tar.gz; cd foreign-crash
> 	$ gdb crashprog crashcore # *-gdb.py files lay here around
> 	 - You are 0wn3d!

Make gdb warn about files that could be autoloaded, but don't load them:

 	$ gdb crashprog crashcore # *-gdb.py files lay here around
        security warning: found possibly unsafe files that could be autoloaded
          foo-gdb.py
          bar-gdb.py
        Start gdb with the -superman option to load them automatically.
        *debug core as usual*
        (gdb)

There's probably a better spelling for that option...  System/package/distro
.py files (printers, and stuff) would be trusted.  The mechanism for that
could be path list based.

> (b) as regular user:
> 	$ cd my/great/project; make
> 	# gdb myprog-using-local-new-gdb.py-pretty-printers

 	$ cd my/great/project; make
 	# gdb -trustothers myprog-using-local-new-gdb.py-pretty-printers

Or the equivalent in ~/.gdbinit -- trustothers-ness possibly enabled with python
(checking for example, if the executable is under a /home/me/myprojects/
directory, or whatever other policy one prefers).  If you forget to specify
the flag, gdb will warn you about the files that could be loaded.

The question is: is this too much inconvenience?  I am willing to give it
a try for a while.

> 
> If we want to fix (a) by default we have to regress (b) in the default case.
> 
> The second question would be which directories are safe and which are not but
> that can be solved by some configuration variable and site-adjustable value.

Yes, agreed.

-- 
Pedro Alves