This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB 7.5: Problems with the auto-load safe-path feature


> Date: Sat, 18 Aug 2012 15:21:28 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> > First, on MS-Windows the file gdb/gdb-gdb.gdb is not loaded, because
> > GDB wants it to be named gdb.exe-gdb.gdb.  I think the .exe suffix
> > should be ignored in this case, so I suggest the patch below.  OK to
> > commit?
> 
> Should it be really host type macro?  Isn't it more a bug gdb/gdb-gdb.gdb is
> created instead of gdb/gdb.exe-gdb.gdb?  Is something like this common for
> other projects on MS-Windows? (If so how does it behave for UNIX-host
> Windows-target cross-projects?)  Just asking if you are already aware of it.

Until now, we had .gdbinit files, which worked on Unix and Windows
alike.  Isn't it true that we now encourage migration from .gdbinit to
FOO-gdb.gdb files?  If so, the issue gets introduced now that didn't
exist before.

But even if .gdbinit files are to stay, and FOO-gdb.gdb are in
addition to them, my point is still valid, IMO: this file might be
coming with the source distribution, not being generated at build
time.  In that case, omitting the .exe suffix will allow the file to
be used on any platform, not just on Unix.  I think this is better.

> > Next, I have trouble understanding how we are supposed to deal with
> > this in, e.g., the Emacs distribution, which comes with a heavily
> > customized .gdbinit file.  There seems to be no way of telling GDB
> > that this .gdbinit is safe, except (a) through command-line arguments,
> > or (b) by adding settings to global or user-private init files.
> 
> Yes, choose either (a) or (b).  I choose add-auto-load-safe-path in ~/.gdbinit
> myself (for my gdb src directory), TIMTOWTDI.

But that is not backward-compatible to older GDB versions, is it?
Here's what I get with GDB 7.4.1:

  D:\usr\eli/.gdbinit:1: Error in sourced command file:
  "on" or "off" expected.

This is with ~/.gdbinit which says just this:

  set auto-load safe-path /

That's why I asked about a backward-compatible way: it's not
inconceivable that someone would have several GDB versions on the same
machine.  And GDB auto-loaded files distributed with other projects
may wish to be compatible to several GDB versions.

> > How can other projects allow seamless loading of their GDB init files, in
> > a way that is compatible with previous GDB versions, and without requiring
> > each user to hack their global/private GDB init files?
> 
> That's the goal of the safe-path feature, so that there is really no way how
> a malicious extracted directory can hijack user's GDB.

I'd hope we could find a better balance between preventing malicious
attacks and punishing legitimate uses.  But I digress.

> > Another problem is that the error message displayed when GDB rejects
> > to auto-load a file, viz.:
> > 
> >    warning: File "D:\gnu\bzr\emacs\trunk\src\.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> > 
> > leaves it to the user to find out where are those safe directories.
> 
> The 'auto-load safe-path' is the key there, I expected this will guide the
> user to use '(help)? (set|show) auto-load safe-path' commands.

It did guide there.  But that didn't help, either:

  (gdb) show auto-load safe-path
  List of directories from which it is safe to auto-load files is $debugdir:$datadir/auto-load.

That's why I wanted to find out what is $debugdir, see below.

> >   (gdb) show data-directory
> >   GDB's data directory is "d:\usr\share\gdb".
> > 
> > But for $debugdir, there's no "show debug-directory"; instead I need
> > to do this:
> > 
> >   (gdb) show debug-file-directory
> >   The directory where separate debug symbols are searched for is "d:\usr\lib\debug".
> 
> Both variables are well documented in the GDB Manual, you have reviewed it.

There's nothing wrong with the manual.  My problem was with
discoverability of these variables's values from within GDB.  When I
was presented with an opaque $debugdir, I wanted to know how close
that was to the source or build directory, thinking that perhaps this
is some misconfiguration issue, or maybe even (gasp!) a bug specific
to MS-Windows.

How about if we show the variable values explicitly in the warning
message, instead of using variables whose values cannot be easily
displayed?

> > and the description does not make me sure this is the right directory,
> > since it does not mention anything about scripts.  At the very least,
> > we should fix the description to mention the scripts.
> 
> Offtopic, see above.

??? How so?  The full doc string of "auto-load safe-path" still
doesn't mention scripts:

  (gdb) help set auto-load safe-path
  Set the list of directories from which it is safe to auto-load files.
  Various files loaded automatically for the 'set auto-load ...' options must
  be located in one of the directories listed by this option.  Warning will be
  printed and file will not be used otherwise.
  Setting this parameter to an empty list resets it to its default value.
  Setting this parameter to '/' (without the quotes) allows any file
  for the 'set auto-load ...' options.  Each directory can be also shell
  wildcard pattern; '*' does not match directory separator.
  This option is ignored for the kinds of files having 'set auto-load ... off'.
  This options has security implications for untrusted inferiors.


> >   (gdb) apropos director
> >   [...]
> >   info auto-load local-gdbinit -- Print whether current directory
> >   [...]
> >   set auto-load local-gdbinit -- Enable or disable auto-loading of
> >   [...]
> >   show auto-load local-gdbinit -- Show whether auto-loading
> > 
> > These truncated descriptions are caused by using ".gdbinit" in the
> > first line of the doc string.  To fix this, we should either use "GDB
> > init" instead of .gdbinit, or remove the code that stops on the first
> > period or comma altogether.
> 
> OK, thanks for the report, I do not use 'apropos'.
> 
> The patch below will make this change, are you OK with it?

Yes, thanks.

> BTW sorry for this note but 7.5 had a long pre-release time to catch these
> issues you are reporting.

There's a limit to how many projects one can pretest, and still do
something useful during the day (assuming GDB maintenance is not what
you get your paycheck for).  I'm heavily invested in Emacs, and am
practically the only person who deals with Windows pretests of Make
and Gawk.  Since there are a couple of people who obviously track the
GDB development on MS-Windows (they tend to report regressions on
trunk within days of their introduction), I hoped any such issues in
GDB will be caught by them, to say nothing of the people who use CVS
versions on Unix, and should have seen these issues a long time ago.

I'm open to ideas how to help make our pre-release testing better, but
that must be a collective effort, it cannot be blamed on a single
person, even if that person is me.  E.g., perhaps we should require at
least one positive success report on each supported platform, or at
least on the more popular ones, before we announce the pre-release a
success and go for the release.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]