detecting failed root shells [Re: itp: static bins / resolving static debian issues]
Michael Stone <mstone@debian.org> writes:
> On Tue, Aug 24, 1999 at 08:43:18AM +0200, Marek Habersack wrote:
> > line). Then we know that what we exec is actually a shell (unless somebody
> > puts something weird as a root's shell - but that's not our problem) and we
> > can forget about the case as above with a perl/whatever script returning a
> > 127 error code. Either way, the error code _bears_ a possibility of being
> > returned by the dynamic loader and it's better to be safe than sorry.
>
> That wasn't the point. Did you try what I wrote? The point was that
> bash's return code is the return code of the program last executed by
> bash--it's not necessarily something determined by bash itself. You
> can't rely on the content of bash's return code because you have *no*
> control over what I run in my bash session, or what it might return. And
> no, it's not better to be safe than sorry if your idea of "safe" has the
> possiblity of starting *two* shells when I use root's shell.
Several programs don't set return codes and on alpha the result being
on the stack is most likely not 0, as it seems to be on PC. Therby you
have a random return code.
Now consider it to be 127 and you type exit and go away. The System
will be left with an root shell left open for everyone.
MfG,
Goswin
Reply to: