SOURCES: gdb-gdbinit-stat.patch (NEW) - read .gdbinit from current...

[Tomasz Wittner]

On Thu 8. of December 2005 18:32, Jakub Bogusz wrote:
[...]
> >
> > > +   if (!homedir
> > > +       || memcmp ((char *) &homebuf, (char *) &cwdbuf, sizeof (struct
> > > stat))) +-    if (!inhibit_gdbinit)
> > > ++    if (!inhibit_gdbinit && (cwdbuf.st_uid == getuid()) &&
> > > (!cwdbuf.st_mode & (S_IWOTH))) +       {
> > > + 	catch_command_errors (source_command, gdbinit, 0, RETURN_MASK_ALL);
> > > +       }
> >
> > Teraz, jeżeli jestem kim jestem i .gdbinit nie jest do zapisu przez
> > wszystkich to mogę korzystać z dobrodziejstw .gdbinit. Jeżeli jednak
> > zrobię su (czyli będę kimś innym niż jestem), żeby debbugować program
> > wymagający uprawnień root'a, to gdb już nie przeczyta .gdbinit . Sytuacja
> > odwrotna do opisanej na http://bugs.gentoo.org/show_bug.cgi?id=88398
> > Osobiście dla mnie ten pacz to tylko utrudnienie - już go u mnie nie ma.
> > Nie chcę, żeby programy mnie chroniły przed samym sobą ;).
>
> Na maszynie jednoużytkownikowej tak. Ale na wieloużytkownikowej
> uruchomienie gdb z $PWD=/tmp (lub odpowiednikiem) mogło dać zupełnie
> niespodziewane efekty.
Jest szansa na ich uniknięcie: gdb -n . Rozumiem, że można też nie być 
świadomym problemu, czy zapomnieć. Za to, w przypadku tego pacza, nie ma 
szansy świadomego użycia .gdbinit'a w opisanej przeze mnie sytuacji, bez 
chown'owania wte i z powrotem. Zmienia on, też, powszechnie znane zachowanie 
programu i oczywiście, jak zwykle, dokumentacja nie jest akualizowana 
(przerabialiśmy to już na rpm-bb-and-short-circuit.patch). Być może 
użytkownik powinien otrzymać jakiś msg o pominięciu .gdbinit i z jakiego 
powodu i mieć coś w stylu --force-reading-gdbinit-from-cwd. Ten pacz, w 
obecnej postaci, jest dla mnie nie do zaakceptowania (co nie oznacza, że mam 
go ochotę poprawiać czy usuwać).

-- 
Tomasz Wittner