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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 17 Jan 2012 17:11:19 +0100, Doug Evans wrote:
> On Tue, Jan 17, 2012 at 1:55 AM, Jan Kratochvil
> <jan.kratochvil@redhat.com> wrote:
> > Besides security problems the automatic execution is even inconvenient:
> > Â Â Â Â$ gdb testsuite/gdb.base/return
> > Â Â Â Â[...]
> > Â Â Â ÂSetting up the environment for debugging gdb.
> > Â Â Â ÂFunction "internal_error" not defined.
> > Â Â Â ÂMake breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
> > Â Â Â ÂFunction "info_command" not defined.
> > Â Â Â ÂMake breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
> > Â Â Â Â.gdbinit:8: Error in sourced command file:
> > Â Â Â ÂArgument required (one or more breakpoint numbers).
> > Â Â Â Â - What had happened? ÂOh, I forgot -nx again!
> 
> This only affects gdb developers though.

It affects also gcc, gas, emacs, former Frysk, ReactOS, there will be more
malicious .gdbinit files; not listed non-intrusive .gdbinit files which only
define some new commands.


> Another way to go is to enhance gdb's .gdbinit to check for which
> binary is being debugged and only do those things when it's gdb (and
> if necessary enhance the scripting language to support such a check).
> Seems generally useful, we should add support for it anyway.

<bite> When one wants to debug gdb in gdb the file gdb/.gdbinit is really the
most destructive as all its various commands succeed making the debugging
session completely unusable. </bite>


> One problem I have with -nx is that it also turns off system.gdbinit.
> I've sometimes wanted to turn off everything but system.gdbinit,
> without having to specify the path to system.gdbinit in -x.

I do not use system.gdbinit but I use home.gdbinit sharing the problem.


> Well, there is make (and I'm sure others).  E.g.,
> echo "default:; @echo Gotcha." > GNUmakefile && make
> :-)

I was even thinking about make but I do not find it as a valid case.
The primary goal of `make' is to read local Makefile - therefore one cannot be
surprised by it.  The primary goal of GDB is to process its arguments.
I would bet some GDB users do not know there exists anything like .gdbinit.


> I don't mind "set auto-load-local-gdbinit", though "set auto-load
> local-gdbinit" feels better, I could do "show auto-load" and see all
> the auto-load settings (assuming we migrate "auto-load-scripts" to
> "auto-load scripts" - though I'm beginning to like plain "scripts" in
> the name less ...).

I sure followed "auto-load-scripts".  I can change it (later).


> If you want to default it to "off", I think I'd give several releases
> warning notice,
> e.g., at least a year, to give enough time to change our minds if the
> user community really doesn't want it. :-)

I find it OK that way.  Maybe there will be some general disagreement.

I need to know this decision to choose the way fixing next security hole
- "set auto-load-scripts" + libthread_db.so.1 as implemented by Google.
So that the other security options/commands can assume it that way.


Thanks,
Jan