bug#9600: 24.0.50; .gdbinit does not run

bug#9600: 24.0.50; .gdbinit does not run

[Richard Stallman]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

I built Emacs in place.  GDB did not run .gdbinit because the file is
writable.  Once I saw that, I knew how to work around it, but it
should not be necessary for everyone that builds Emacs in place to
work around it.  It should be fixed in Emacs so the problem does not
occur.

One idea is, rename .gdbinit to .gdbinit-real,
and have compilation generate a trivial read-only .gdbinit
which only says `source .gdbinit-real'.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/home/rms/emacs-bzr/trunk/etc/DEBUG.


In GNU Emacs 24.0.50.4 (mips64el-unknown-linux-gnu, GTK+ Version 2.12.12)
 of 2011-09-22 on theobromine2
configured using `configure  'CFLAGS=-g -O1''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  gpm-mouse-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
TAB RET g C-u C-p C-p C-p C-o C-x o C-g ESC x c l e 
a C-g ESC x c l e a u DEL n u p RET C-o C-x o C-x o 
C-n C-o C-n C-o C-p C-o C-x o C-x o C-n C-o C-x o C-x 
1 C-u C-n C-u C-n C-n C-n C-n C-n C-n I t SPC d o e 
s n ' t SPC s e e m SPC t o SPC g DEL b e C-a C-k I 
SPC d o u b t SPC i t SPC i s SPC G D B SPC DEL ' s 
SPC f a i l DEL DEL u l d DEL , DEL r , SPC DEL DEL 
DEL t , SPC s i n c e SPC m y SPC G D B SPC e x e c 
u t a b l e SPC w a s SPC c m p DEL DEL o m p i l e 
d SPC i n SPC 2 0 0 8 RET a n d SPC i SPC a m p r e 
ESC DEL ESC DEL i t SPC i s SPC u n l i k e l y SPC 
I SPC h a e SPC DEL DEL v e SPC n o t SPC r u n SPC 
x b a c k t r a c e SPC b e f o r e . DEL ESC DEL b 
e f o r e SPC ESC DEL s i n c e SPC t h e n . C-x C-s 
C-a C-p C-p C-p C-p C-p ESC f ESC f ESC d C-x C-s C-u 
C-x m ESC x r e DEL DEL r e p o TAB r TAB RET

Recent messages:
Quit [2 times]
find-file-noselect: Command attempted to use minibuffer while in minibuffer
Redisplaying...done
Quit
Auto-saving...done
Saving file /home/rms/outgoing/out-5...
Wrote /home/rms/outgoing/out-5
Saving file /home/rms/outgoing/out-5...
Wrote /home/rms/outgoing/out-5
Making completion list...

Load-path shadows:
None found.

Features:
(gud mail-extr pp shadow emacsbug compare-w log-view parse-time
mule-util quail ispell speedbar sb-image ezimage dframe assoc ind-util
edmacro kmacro dired-aux rmailout sgml-mode ansi-color shell pcomplete
grep qp dabbrev newcomment warnings cl byte-opt compile comint
bytecomp byte-compile cconv macroexp find-func help-mode view help-fns
cc-mode cc-fonts cc-guess cc-bytecomp cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs whitespace diff-mode log-edit
easy-mmode ring pcvs-util vc-sccs vc-svn vc-cvs vc-rcs vc-dir ewoc vc
ediff-merg ediff-diff ediff-wind ediff-help ediff-util ediff-mult
ediff-init ediff vc-dispatcher add-log multi-isearch vc-bzr mailalias
rmailmm message sendmail format-spec rfc822 mml easymenu mml-sec
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader
mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils dired regexp-opt t-mouse time-date battery paren cus-start
cus-load tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win
x-dnd tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
loaddefs button faces cus-face files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar
gtk x-toolkit x multi-tty emacs)


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9600: 24.0.50; .gdbinit does not run

[Eli Zaretskii]

> Date: Sun, 25 Sep 2011 13:34:20 -0400
> From: Richard Stallman <rms@gnu.org>
> 
> I built Emacs in place.  GDB did not run .gdbinit because the file is
> writable.  Once I saw that, I knew how to work around it, but it
> should not be necessary for everyone that builds Emacs in place to
> work around it.  It should be fixed in Emacs so the problem does not
> occur.

FWIW, I cannot reproduce this with GDB 7.3, 7.2, or 7.1 and with
today's Emacs trunk.  I couldn't try earlier GDB versions.

What are the exact permissions of your .gdbinit?  Mine are 664 in one
tree and 666 in another; both work.

bug#9600: 24.0.50; .gdbinit does not run

[Sven Joachim]

On 2011-09-25 20:04 +0200, Eli Zaretskii wrote:

>> Date: Sun, 25 Sep 2011 13:34:20 -0400
>> From: Richard Stallman <rms@gnu.org>
>> 
>> I built Emacs in place.  GDB did not run .gdbinit because the file is
>> writable.  Once I saw that, I knew how to work around it, but it
>> should not be necessary for everyone that builds Emacs in place to
>> work around it.  It should be fixed in Emacs so the problem does not
>> occur.
>
> FWIW, I cannot reproduce this with GDB 7.3, 7.2, or 7.1 and with
> today's Emacs trunk.  I couldn't try earlier GDB versions.
>
> What are the exact permissions of your .gdbinit?  Mine are 664 in one
> tree and 666 in another; both work.

Richard may have a Debian-patched GDB which complains if the .gdbinit
file is world writable.

Cheers,
       Sven

bug#9600: 24.0.50; .gdbinit does not run

[Eli Zaretskii]

> From: Sven Joachim <svenjoac@gmx.de>
> Cc: rms@gnu.org,  9600@debbugs.gnu.org
> Date: Sun, 25 Sep 2011 20:22:19 +0200
> 
> Richard may have a Debian-patched GDB which complains if the .gdbinit
> file is world writable.

I guess now I know why I build my own GDB...

bug#9600: 24.0.50; .gdbinit does not run

[Richard Stallman]

    Richard may have a Debian-patched GDB which complains if the .gdbinit
    file is world writable.

If this is a Debian patch, maybe that explains things.
I probably did something to make .gdbinit read-only
that worked with CVS but not with BZR.

Would it work for me to make my copy of .gdbinit read-only
but continue updating it with bzr?  Can bzr handle that?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9600: 24.0.50; .gdbinit does not run

[Eli Zaretskii]

> Date: Sun, 25 Sep 2011 21:00:36 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, 9600@debbugs.gnu.org
> 
> Would it work for me to make my copy of .gdbinit read-only
> but continue updating it with bzr?  Can bzr handle that?

Yes, I think so.  At least if I chmod a file to remove all of its
write bits, "bzr modified" doesn't call out that file, and if I modify
it and "bzr revert", the reverted file keeps the mode bits I set on
it.

But I would really suggest to get and/or build a later GDB from
official sources.

bug#9600: 24.0.50; .gdbinit does not run

[Glenn Morris]

Eli Zaretskii wrote:

> Yes, I think so.  At least if I chmod a file to remove all of its
> write bits, "bzr modified" doesn't call out that file, and if I modify
> it and "bzr revert", the reverted file keeps the mode bits I set on
> it.
>
> But I would really suggest to get and/or build a later GDB from
> official sources.

AFAICS, rms still has not said what the permissions of his gdbinit file
were, beyond "writable". It seems this must mean "world-writable".

I tested with Debian testing's gdb "7.3-debian". A gdbinit file writable
by me was fine, a world-writable gdbinit was rejected with

  warning: not using untrusted file ".gdbinit"

This seems entirely reasonable to me [1]. No need to build another gdb.
Just use a sensible umask when checking Emacs out from the repository.

Since I hope that everyone building Emacs from source does not use
`umask 000', I don't think any Emacs changes are needed.

[1] Also: http://www.cygwin.com/ml/gdb-patches/2005-05/msg00648.html

bug#9600: 24.0.50; .gdbinit does not run

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: rms@gnu.org,  9600@debbugs.gnu.org,  svenjoac@gmx.de
> Date: Mon, 26 Sep 2011 03:26:18 -0400
> 
> AFAICS, rms still has not said what the permissions of his gdbinit file
> were, beyond "writable". It seems this must mean "world-writable".

Most probably, because this is what I have in my bzr branches.  I
guess that's because of umask, see below.

> I tested with Debian testing's gdb "7.3-debian". A gdbinit file writable
> by me was fine, a world-writable gdbinit was rejected with
> 
>   warning: not using untrusted file ".gdbinit"

Stock GDB does not reject such a .gdbinit.  That was the gist of what
I was saying.

> This seems entirely reasonable to me

It was sufficiently controversial at the time to not make it into the
official GDB.

> Since I hope that everyone building Emacs from source does not use
> `umask 000'

I do, FWIW.  Don't ask me why, it's something I have in my .bash_login
since about forever.

> I don't think any Emacs changes are needed.

No Emacs changes are needed in any case, since RMS can chmod the file,
and bzr will not touch the write mode bits.

bug#9600: 24.0.50; .gdbinit does not run

[Glenn Morris]

Eli Zaretskii wrote:

> No Emacs changes are needed in any case, since RMS can chmod the file,
> and bzr will not touch the write mode bits.

Right, but he was saying that if everyone had to do that, some other
solution should be found. But I think trusting 'umask 000' folks like
you and he are in the minority. ;)

bug#9600: 24.0.50; .gdbinit does not run

[Richard Stallman]

    I tested with Debian testing's gdb "7.3-debian". A gdbinit file writable
    by me was fine, a world-writable gdbinit was rejected with

      warning: not using untrusted file ".gdbinit"

    This seems entirely reasonable to me [1]. No need to build another gdb.
    Just use a sensible umask when checking Emacs out from the repository.

When the executable is world-writable, there is no reason at all why
GDB should care whether .gdbinit is world-writable.

But we can't implement that here.

    Just use a sensible umask when checking Emacs out from the repository.

I think my choice of umask is totally sensible.  Where did you get
the idea it is not?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9600: 24.0.50; .gdbinit does not run

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> I tested with Debian testing's gdb "7.3-debian". A gdbinit file writable
> by me was fine, a world-writable gdbinit was rejected with
>
>   warning: not using untrusted file ".gdbinit"
>
> This seems entirely reasonable to me [1].

That really should only be checking write bits outside of the current
umask.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#9600: 24.0.50; .gdbinit does not run

[Glenn Morris]

close 9600
stop

Richard Stallman wrote:

> But we can't implement that here.

No, I don't think Emacs should do anything to work around gdb security
features, so I am closing this report.

bug#9600: 24.0.50; .gdbinit does not run

[Glenn Morris]

Richard Stallman wrote:

>     Just use a sensible umask when checking Emacs out from the repository.
>
> I think my choice of umask is totally sensible.  Where did you get
> the idea it is not?

This is off-topic for Emacs, but let me rephrase that to say that you
have an uncommon setting of umask. For example, I do not know of any
distribution that has such a mask by default for user accounts. So
people who have given themselves such a umask presumably know what they
are doing and how to deal with any file permission issues that may occur
as a result. (For example, you may also have problems with  ~/.ssh files.)

bug#9600: 24.0.50; .gdbinit does not run

[Richard Stallman]

    This is off-topic for Emacs, but let me rephrase that to say that you
    have an uncommon setting of umask. For example, I do not know of any
    distribution that has such a mask by default for user accounts. So
    people who have given themselves such a umask presumably know what they
    are doing and how to deal with any file permission issues that may occur
    as a result.

As a general point, there is no reason Emacs should not help users
work around problems they may encounter, even just a few users.

But I agree there is no need in this case.  The crucial point
is knowing that bzr can cope with making the file read-only.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/