RFC: Check permissions of .gdbinit files

RFC: Check permissions of .gdbinit files

[Daniel Jacobowitz]

Gentoo recently published a security update for GDB, citing the fact that
GDB would load .gdbinit from the current directory even if that was owned by
another user.  I'm not sure how I feel about running GDB in an untrusted
directory or on untrusted binaries and expecting it to behave sensibly, but
this particular issue is easy to fix.  Here's my suggested fix; it's not the
same as Gentoo's.  If .gdbinit is world writable or owned by a different
user, refuse to open it (and warn the user).

Anyone have opinions on this change?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

2005-05-30  Daniel Jacobowitz  <dan@codesourcery.com>

	* Makefile.in (cli-cmds.o): Update.
	* main.c (captured_main): Pass -1 to source_command when loading
	gdbinit files.
	* cli/cli-cmds.c: Include "gdb_stat.h" and <fcntl.h>.
	(source_command): Update documentation.  Check permissions if
	FROM_TTY is -1.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.733
diff -u -p -r1.733 Makefile.in
--- Makefile.in	22 May 2005 20:36:18 -0000	1.733
+++ Makefile.in	30 May 2005 18:46:16 -0000
@@ -2766,7 +2766,7 @@ cli-cmds.o: $(srcdir)/cli/cli-cmds.c $(d
 	$(expression_h) $(frame_h) $(value_h) $(language_h) $(filenames_h) \
 	$(objfiles_h) $(source_h) $(disasm_h) $(ui_out_h) $(top_h) \
 	$(cli_decode_h) $(cli_script_h) $(cli_setshow_h) $(cli_cmds_h) \
-	$(tui_h)
+	$(tui_h) $(gdb_stat_h)
 	$(CC) -c $(INTERNAL_CFLAGS) $(srcdir)/cli/cli-cmds.c
 cli-decode.o: $(srcdir)/cli/cli-decode.c $(defs_h) $(symtab_h) \
 	$(gdb_regex_h) $(gdb_string_h) $(ui_out_h) $(cli_cmds_h) \
Index: main.c
===================================================================
RCS file: /cvs/src/src/gdb/main.c,v
retrieving revision 1.51
diff -u -p -r1.51 main.c
--- main.c	2 Apr 2005 20:25:22 -0000	1.51
+++ main.c	30 May 2005 18:46:16 -0000
@@ -604,7 +604,7 @@ extern int gdbtk_test (char *);
 
       if (!inhibit_gdbinit)
 	{
-	  catch_command_errors (source_command, homeinit, 0, RETURN_MASK_ALL);
+	  catch_command_errors (source_command, homeinit, -1, RETURN_MASK_ALL);
 	}
 
       /* Do stats; no need to do them elsewhere since we'll only
@@ -691,7 +691,7 @@ extern int gdbtk_test (char *);
       || memcmp ((char *) &homebuf, (char *) &cwdbuf, sizeof (struct stat)))
     if (!inhibit_gdbinit)
       {
-	catch_command_errors (source_command, gdbinit, 0, RETURN_MASK_ALL);
+	catch_command_errors (source_command, gdbinit, -1, RETURN_MASK_ALL);
       }
 
   for (i = 0; i < ncmd; i++)
Index: cli/cli-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-cmds.c,v
retrieving revision 1.61
diff -u -p -r1.61 cli-cmds.c
--- cli/cli-cmds.c	27 May 2005 04:39:33 -0000	1.61
+++ cli/cli-cmds.c	30 May 2005 18:46:17 -0000
@@ -37,6 +37,7 @@
 #include "objfiles.h"
 #include "source.h"
 #include "disasm.h"
+#include "gdb_stat.h"
 
 #include "ui-out.h"
 
@@ -50,6 +51,8 @@
 #include "tui/tui.h"		/* For tui_active et.al.   */
 #endif
 
+#include <fcntl.h>
+
 /* Prototypes for local command functions */
 
 static void complete_command (char *, int);
@@ -419,30 +422,54 @@ cd_command (char *dir, int from_tty)
     pwd_command ((char *) 0, 1);
 }
 \f
+/* Load a GDB command file whose name is given in ARGS.  FROM_TTY may
+   be -1, in which case we are loading a gdbinit file; in that case,
+   be paranoid about unsafe files.  */
+
 void
 source_command (char *args, int from_tty)
 {
-  FILE *stream;
+  FILE *stream = NULL;
+  int fd;
   struct cleanup *old_cleanups;
   char *file = args;
 
   if (file == NULL)
-    {
-      error (_("source command requires pathname of file to source."));
-    }
+    error (_("source command requires pathname of file to source."));
 
   file = tilde_expand (file);
   old_cleanups = make_cleanup (xfree, file);
 
-  stream = fopen (file, FOPEN_RT);
-  if (!stream)
+  fd = open (file, O_RDONLY);
+  if (fd != -1)
+    stream = fdopen (fd, FOPEN_RT);
+  if (stream == NULL)
     {
-      if (from_tty)
+      if (from_tty > 0)
 	perror_with_name (file);
       else
 	return;
     }
 
+#ifdef HAVE_GETUID
+  if (from_tty == -1)
+    {
+      struct stat statbuf;
+      if (fstat (fd, &statbuf) < 0)
+	{
+	  perror_with_name (file);
+	  fclose (stream);
+	  return;
+	}
+      if (statbuf.st_uid != getuid () || (statbuf.st_mode & S_IWOTH))
+	{
+	  warning (_("not using untrusted file \"%s\""), file);
+	  fclose (stream);
+	  return;
+	}
+    }
+#endif
+
   script_from_file (stream, file);
 
   do_cleanups (old_cleanups);

Re: RFC: Check permissions of .gdbinit files

[Nathan J. Williams]

Daniel Jacobowitz <drow@false.org> writes:

> Gentoo recently published a security update for GDB, citing the fact that
> GDB would load .gdbinit from the current directory even if that was owned by
> another user.  I'm not sure how I feel about running GDB in an untrusted
> directory or on untrusted binaries and expecting it to behave sensibly, but
> this particular issue is easy to fix.  Here's my suggested fix; it's not the
> same as Gentoo's.  If .gdbinit is world writable or owned by a different
> user, refuse to open it (and warn the user).
> 
> Anyone have opinions on this change?

I think the "owned by a different user" change is problematic. I've
used build systems that autogenerated .gdbinit files in the build
tree, and it would be entirely sensible for one developer to go and
debug another developer's build.

It does seem reasonable to refuse to execute a world-writable
.gdbinit.

        - Nathan

Re: RFC: Check permissions of .gdbinit files

[Daniel Jacobowitz]

On Mon, May 30, 2005 at 03:01:28PM -0400, Nathan J. Williams wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > Gentoo recently published a security update for GDB, citing the fact that
> > GDB would load .gdbinit from the current directory even if that was owned by
> > another user.  I'm not sure how I feel about running GDB in an untrusted
> > directory or on untrusted binaries and expecting it to behave sensibly, but
> > this particular issue is easy to fix.  Here's my suggested fix; it's not the
> > same as Gentoo's.  If .gdbinit is world writable or owned by a different
> > user, refuse to open it (and warn the user).
> > 
> > Anyone have opinions on this change?
> 
> I think the "owned by a different user" change is problematic. I've
> used build systems that autogenerated .gdbinit files in the build
> tree, and it would be entirely sensible for one developer to go and
> debug another developer's build.

Well that's the whole point.  You'll get a warning; would you be
happier if the warning explicitly suggested "source .gdbinit"?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: Check permissions of .gdbinit files

[Nathan J. Williams]

Daniel Jacobowitz <drow@false.org> writes:

> > I think the "owned by a different user" change is problematic. I've
> > used build systems that autogenerated .gdbinit files in the build
> > tree, and it would be entirely sensible for one developer to go and
> > debug another developer's build.
> 
> Well that's the whole point.  You'll get a warning; would you be
> happier if the warning explicitly suggested "source .gdbinit"?

I guess. I think I don't agree that this is a problem that needs
solving, fundamentally.

        - Nathan

Re: RFC: Check permissions of .gdbinit files

[Daniel Jacobowitz]

On Mon, May 30, 2005 at 03:46:17PM -0400, Nathan J. Williams wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > > I think the "owned by a different user" change is problematic. I've
> > > used build systems that autogenerated .gdbinit files in the build
> > > tree, and it would be entirely sensible for one developer to go and
> > > debug another developer's build.
> > 
> > Well that's the whole point.  You'll get a warning; would you be
> > happier if the warning explicitly suggested "source .gdbinit"?
> 
> I guess. I think I don't agree that this is a problem that needs
> solving, fundamentally.

I'm not completely sure that I disagree.  But it's worth talking about
at least.  Here's the problem case:

<user> Foo is broken!
<root> What do you want me to do about it?
<user> Well, there's a core dump in /blah.
<root> OK

# cd /blah
# gdb /bin/foo core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux".
Hi!
You have been owned.
(gdb)

I wouldn't expect GDB to execute code in that case, but it does.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: Check permissions of .gdbinit files

[Jason Molenda]

On May 30, 2005, at 12:46 PM, Nathan J. Williams wrote:

> I guess. I think I don't agree that this is a problem that needs
> solving, fundamentally.


I don't have a strong opinion either way, but it's not hard to  
imagine scenarios where it could be a problem.  I tend to build  
little programs in /tmp and run gdb on them while working on a  
problem; someone who put a .gdbinit in /tmp with a shell command  
would trick me.  Then again, I don't work in an environment where  
anyone would even think of doing something like that..

J

Re: RFC: Check permissions of .gdbinit files

[Eli Zaretskii]

> Date: Mon, 30 May 2005 14:52:01 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Gentoo recently published a security update for GDB, citing the fact that
> GDB would load .gdbinit from the current directory even if that was owned by
> another user.  I'm not sure how I feel about running GDB in an untrusted
> directory or on untrusted binaries and expecting it to behave sensibly, but
> this particular issue is easy to fix.  Here's my suggested fix; it's not the
> same as Gentoo's.  If .gdbinit is world writable or owned by a different
> user, refuse to open it (and warn the user).
> 
> Anyone have opinions on this change?

Hmm... bother.  This change might break some of the non-Posix
platforms.  Perhaps I missed something, but AFAICS MinGW lacks the
definition of S_IWOTH, so this will fail to compile for MinGW.  But
even if it did compile, the MinGW version of `fstat' returns the
S_IWOTH bit set for all files, so the MinGW port will probably always
display the warning.

The DJGPP port will not be affected: it does have S_IWOTH and it
reports the S_IWOTH bit as reset.  Can't easily check Cygwin here, but
I'm guessing it will do TRT here as well.

> +    error (_("source command requires pathname of file to source."));

I think the message text should begin with a capital letter (yes, I
know the original didn't do it, either).

> -  stream = fopen (file, FOPEN_RT);
> -  if (!stream)
> +  fd = open (file, O_RDONLY);
> +  if (fd != -1)
> +    stream = fdopen (fd, FOPEN_RT);

Could you please tell why you replaced `fopen' with `open'+`fdopen'?

> +      if (statbuf.st_uid != getuid () || (statbuf.st_mode & S_IWOTH))

Shouldn't we allow this to go unnoticed for root?

> +	  warning (_("not using untrusted file \"%s\""), file);

I think the message text should begin with a capital letter.

Last, but not least: if we decide to make such a change (which to my
HO sounds like a good idea, in general), we should describe this
subtlety (and the warning it could produce) in the user's manual.

Re: RFC: Check permissions of .gdbinit files

[Daniel Jacobowitz]

On Tue, May 31, 2005 at 12:54:53AM +0300, Eli Zaretskii wrote:
> > Date: Mon, 30 May 2005 14:52:01 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > Gentoo recently published a security update for GDB, citing the fact that
> > GDB would load .gdbinit from the current directory even if that was owned by
> > another user.  I'm not sure how I feel about running GDB in an untrusted
> > directory or on untrusted binaries and expecting it to behave sensibly, but
> > this particular issue is easy to fix.  Here's my suggested fix; it's not the
> > same as Gentoo's.  If .gdbinit is world writable or owned by a different
> > user, refuse to open it (and warn the user).
> > 
> > Anyone have opinions on this change?
> 
> Hmm... bother.  This change might break some of the non-Posix
> platforms.  Perhaps I missed something, but AFAICS MinGW lacks the
> definition of S_IWOTH, so this will fail to compile for MinGW.  But
> even if it did compile, the MinGW version of `fstat' returns the
> S_IWOTH bit set for all files, so the MinGW port will probably always
> display the warning.
> 
> The DJGPP port will not be affected: it does have S_IWOTH and it
> reports the S_IWOTH bit as reset.  Can't easily check Cygwin here, but
> I'm guessing it will do TRT here as well.

Bother; I thought about the portability for a while, but didn't quite
consider this.  We're still OK though - the whole thing is surrounded
by HAVE_GETUID, and MinGW does not have GETUID, if I understand
correctly.  I think it's plausible to assume that S_IWOTH will be
defined if getuid() is; does that seem reasonable to you?

> > +    error (_("source command requires pathname of file to source."));
> 
> I think the message text should begin with a capital letter (yes, I
> know the original didn't do it, either).

I was pretty sure that the convention was lowercase letter, and no
trailing period.  But I don't think this is documented anywhere, and
the source is wildly inconsistent.  I could easily be remembering wrong
:-)

> > -  stream = fopen (file, FOPEN_RT);
> > -  if (!stream)
> > +  fd = open (file, O_RDONLY);
> > +  if (fd != -1)
> > +    stream = fdopen (fd, FOPEN_RT);
> 
> Could you please tell why you replaced `fopen' with `open'+`fdopen'?

In order to have the file descriptor, for fstat.  It occurs to me now
that "fileno" could be used for this; I am not sure how portable fileno
is (my system's man page for it is somewhat ambiguous on the subject)
but I see that we use it already, so the answer is "portable enough". 
That would probably be cleaner.

> > +      if (statbuf.st_uid != getuid () || (statbuf.st_mode & S_IWOTH))
> 
> Shouldn't we allow this to go unnoticed for root?

No, that's especially when we shouldn't.  It's root that wants to be
paranoid about silently using some user's .gdbinit file.  This is the
opposite problem to access checks in a privileged program; we want no
more "privileges" for the superuser here.

> > +	  warning (_("not using untrusted file \"%s\""), file);
> 
> I think the message text should begin with a capital letter.
> 
> Last, but not least: if we decide to make such a change (which to my
> HO sounds like a good idea, in general), we should describe this
> subtlety (and the warning it could produce) in the user's manual.

Where would you suggest?  Ah, never mind, I see there is a section on
.gdbinit already.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: Check permissions of .gdbinit files

[Eli Zaretskii]

> Date: Mon, 30 May 2005 18:42:00 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sourceware.org
> 
> Bother; I thought about the portability for a while, but didn't quite
> consider this.  We're still OK though - the whole thing is surrounded
> by HAVE_GETUID, and MinGW does not have GETUID, if I understand
> correctly.

Maybe, I don't know.  Isn't the MinGW port linked against some
library, such as libgw32c.a, that implements more Posix stuff?

In any case, the other issue still remains: if they do have getuid and
S_IWOTH, non-readonly files will be reported world-writable.  So I'd
suggest to either disable this feature entirely on Windows platforms,
or write a Windows specific code that uses the Win32 API to get file
ownership (GetSecurityInfo or some such).

> > > +    error (_("source command requires pathname of file to source."));
> > 
> > I think the message text should begin with a capital letter (yes, I
> > know the original didn't do it, either).
> 
> I was pretty sure that the convention was lowercase letter, and no
> trailing period.  But I don't think this is documented anywhere, and
> the source is wildly inconsistent.  I could easily be remembering wrong
> :-)

I'm not aware of any such conventions.  Starting a sentence with a
capital letter sounds like the right choice, though.

> > Could you please tell why you replaced `fopen' with `open'+`fdopen'?
> 
> In order to have the file descriptor, for fstat.  It occurs to me now
> that "fileno" could be used for this; I am not sure how portable fileno
> is

`fileno' is defined by Posix, so we definitely can use it.

> > Last, but not least: if we decide to make such a change (which to my
> > HO sounds like a good idea, in general), we should describe this
> > subtlety (and the warning it could produce) in the user's manual.
> 
> Where would you suggest?  Ah, never mind, I see there is a section on
> .gdbinit already.

Right.

Re: RFC: Check permissions of .gdbinit files

[Christopher Faylor]

On Tue, May 31, 2005 at 08:46:03AM +0300, Eli Zaretskii wrote:
>> Date: Mon, 30 May 2005 18:42:00 -0400
>> From: Daniel Jacobowitz <drow@false.org>
>> Cc: gdb-patches@sourceware.org
>> 
>> Bother; I thought about the portability for a while, but didn't quite
>> consider this.  We're still OK though - the whole thing is surrounded
>> by HAVE_GETUID, and MinGW does not have GETUID, if I understand
>> correctly.
>
>Maybe, I don't know.  Isn't the MinGW port linked against some
>library, such as libgw32c.a, that implements more Posix stuff?

MinGW does not have getuid().  Or, at least the version that I have
checked out doesn't have it.  It is possible to emulate getuid on WinNT+
and it is possible to fill in all of the fields in st_mode with
reasonable things but, AFAIK, Mingw's implementation doesn't do this.

>In any case, the other issue still remains: if they do have getuid and
>S_IWOTH, non-readonly files will be reported world-writable.  So I'd
>suggest to either disable this feature entirely on Windows platforms,
>or write a Windows specific code that uses the Win32 API to get file
>ownership (GetSecurityInfo or some such).

Did anyone read Ulrich Drepper's recent rant about this kind of thing?  :-)

Are you implying that we should defend against the day when mingw starts
exporting getuid?  If we're postulating that getuid might exist someday
can't we just postulate that st_mode has been fixed at the same time?

cgf

Re: RFC: Check permissions of .gdbinit files

[Eli Zaretskii]

> Date: Tue, 31 May 2005 18:22:33 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> >>>In any case, the other issue still remains: if they do have getuid and
> >>>S_IWOTH, non-readonly files will be reported world-writable.  So I'd
> >>>suggest to either disable this feature entirely on Windows platforms,
> >>>or write a Windows specific code that uses the Win32 API to get file
> >>>ownership (GetSecurityInfo or some such).
> >>
> >>Did anyone read Ulrich Drepper's recent rant about this kind of thing?
> >>:-)
> >
> >I don't think I've read it.  I'd appreciate a URL.
> 
> http://www.livejournal.com/users/udrepper/7326.html

Thanks.

This isn't new to me: I remember sparring with Ulrich about these
issues as far as 7 years ago (which didn't prevent us from drinking
beer together when we met ;-).

Anyway, I hope you didn't seriously mean to say that I'm such a
minority in this case, because I already said that what I wrote in
this thread can be disregarded at will.

Re: RFC: Check permissions of .gdbinit files

[Christopher Faylor]

On Thu, Jun 02, 2005 at 06:51:40AM +0300, Eli Zaretskii wrote:
>> Date: Tue, 31 May 2005 18:22:33 -0400
>> From: Christopher Faylor <me@cgf.cx>
>> 
>> >>>In any case, the other issue still remains: if they do have getuid and
>> >>>S_IWOTH, non-readonly files will be reported world-writable.  So I'd
>> >>>suggest to either disable this feature entirely on Windows platforms,
>> >>>or write a Windows specific code that uses the Win32 API to get file
>> >>>ownership (GetSecurityInfo or some such).
>> >>
>> >>Did anyone read Ulrich Drepper's recent rant about this kind of thing?
>> >>:-)
>> >
>> >I don't think I've read it.  I'd appreciate a URL.
>> 
>> http://www.livejournal.com/users/udrepper/7326.html
>
>Thanks.
>
>This isn't new to me: I remember sparring with Ulrich about these
>issues as far as 7 years ago (which didn't prevent us from drinking
>beer together when we met ;-).

Oh, yes.  I've had a similar (probably more abbreviated) discussion
with him as well.

In an odd sort of way, I sort of agree with him.

cgf

Re: RFC: Check permissions of .gdbinit files

[Eli Zaretskii]

> Date: Thu, 2 Jun 2005 00:26:10 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> In an odd sort of way, I sort of agree with him.

Can't say I do (as you can see from my comments on his essay).

Re: RFC: Check permissions of .gdbinit files

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> Gentoo recently published a security update for GDB, citing the fact that
> GDB would load .gdbinit from the current directory even if that was owned by
> another user.  I'm not sure how I feel about running GDB in an untrusted
> directory or on untrusted binaries and expecting it to behave sensibly, but
> this particular issue is easy to fix.  Here's my suggested fix; it's not the
> same as Gentoo's.  If .gdbinit is world writable or owned by a different
> user, refuse to open it (and warn the user).
>
> Anyone have opinions on this change?

IMHO you should at least allow the same group owner.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFC: Check permissions of .gdbinit files

[Daniel Jacobowitz]

On Tue, May 31, 2005 at 12:29:24AM +0200, Andreas Schwab wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > Gentoo recently published a security update for GDB, citing the fact that
> > GDB would load .gdbinit from the current directory even if that was owned by
> > another user.  I'm not sure how I feel about running GDB in an untrusted
> > directory or on untrusted binaries and expecting it to behave sensibly, but
> > this particular issue is easy to fix.  Here's my suggested fix; it's not the
> > same as Gentoo's.  If .gdbinit is world writable or owned by a different
> > user, refuse to open it (and warn the user).
> >
> > Anyone have opinions on this change?
> 
> IMHO you should at least allow the same group owner.

Can you explain why?  I'm trying not to encode too much site policy
into GDB; that's not its business.  Many people still use setups with a
single "users" group for most users.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: Check permissions of .gdbinit files

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Tue, May 31, 2005 at 12:29:24AM +0200, Andreas Schwab wrote:
>> Daniel Jacobowitz <drow@false.org> writes:
>> 
>> > Gentoo recently published a security update for GDB, citing the fact that
>> > GDB would load .gdbinit from the current directory even if that was owned by
>> > another user.  I'm not sure how I feel about running GDB in an untrusted
>> > directory or on untrusted binaries and expecting it to behave sensibly, but
>> > this particular issue is easy to fix.  Here's my suggested fix; it's not the
>> > same as Gentoo's.  If .gdbinit is world writable or owned by a different
>> > user, refuse to open it (and warn the user).
>> >
>> > Anyone have opinions on this change?
>> 
>> IMHO you should at least allow the same group owner.
>
> Can you explain why?

If you have a group of developers working on the same project you might
want a shared .gdbinit somewhere.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFC: Check permissions of .gdbinit files

[Daniel Jacobowitz]

On Tue, May 31, 2005 at 12:49:05AM +0200, Andreas Schwab wrote:
> If you have a group of developers working on the same project you might
> want a shared .gdbinit somewhere.

I'm leaning towards handling that by suggesting in the manual that you
use "source .gdbinit" in $HOME/.gdbinit for that.  I agree that it's a
little less convenient.  I dunno.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: Check permissions of .gdbinit files

[Bob Rossi]

On Mon, May 30, 2005 at 07:00:26PM -0400, Daniel Jacobowitz wrote:
> On Tue, May 31, 2005 at 12:49:05AM +0200, Andreas Schwab wrote:
> > If you have a group of developers working on the same project you might
> > want a shared .gdbinit somewhere.
> 
> I'm leaning towards handling that by suggesting in the manual that you
> use "source .gdbinit" in $HOME/.gdbinit for that.  I agree that it's a
> little less convenient.  I dunno.

The really bad thing about this is that you can't source a generic path.
For instance, source $GROUP_GDB_INIT_DIR/.gdbinit

Make's it very hard to make the .gdbinit scripts configurable. For
instance, since this is for .gdbinit files that are typically not in
$HOME, you would probably have one for every program that is built (or
something like that). So if you were unfortunate enough to be effected
by this change, you would have to change your $HOME/.gdbinit path each
time to point to the .gdbinit you wanted to source. This would be
annoying. 

What if we had GDB prompt the user to determine if they wanted to read
the .gdbinit file in? Then we could add another configuration variable
to GDB that allowed it to always read in the files. That way, by
default GDB would be more safe, but for the rest of us, it would work
the way it always has.

Thanks,
Bob Rossi

Re: RFC: Check permissions of .gdbinit files

[Stan Shebs]

Bob Rossi wrote:

>
>What if we had GDB prompt the user to determine if they wanted to read
>the .gdbinit file in? Then we could add another configuration variable
>to GDB that allowed it to always read in the files. That way, by
>default GDB would be more safe, but for the rest of us, it would work
>the way it always has.
>
I like this idea, or some variation. A developer working in a
less-secure environment can set the variable (env var?) to ask
first before doing, while in an environment like Apple where you
have a thousand engineers sharing files in all kinds of weird ways,
you can set it to "if an intruder gets this far in, .gdbinit is the
least of our worries."

Stan

Re: RFC: Check permissions of .gdbinit files

[Mark Kettenis]

   Date: Mon, 30 May 2005 14:52:01 -0400
   From: Daniel Jacobowitz <drow@false.org>

   Gentoo recently published a security update for GDB, citing the fact that
   GDB would load .gdbinit from the current directory even if that was owned by
   another user.  I'm not sure how I feel about running GDB in an untrusted
   directory or on untrusted binaries and expecting it to behave sensibly, but
   this particular issue is easy to fix.  Here's my suggested fix; it's not the
   same as Gentoo's.  If .gdbinit is world writable or owned by a different
   user, refuse to open it (and warn the user).

   Anyone have opinions on this change?

What does vi do with respect to .exrc?  It might make sense to follow
its example.

Mark