Re: itp: static bins / resolving static debian issues

[Justin Wells <jread@semiotek.com>]

On Sat, Aug 21, 1999 at 08:23:53PM -0700, Nathaniel Smith wrote:
> On Sat, Aug 21, 1999 at 10:54:35PM -0400, Justin Wells wrote:
> > 
> > Sorry, "exec /bin/bash" will cause you to get logged out if libc is 
> > broken. The exec will succeed, bash will try and load its dynamic 
> > libraries, it will fail, and it will exit. Try it.
> 
> I did, actually (as I mentioned), using hard links to sash and bash in 
> a test directory.

Try actually removing a library. Obviously do this with care, and be 
prepared for the possibility that many things will fail. Start up 
two sash shells (just in case) and then do this:

    cd /lib
    mv libc.so.6 libc.so.6.bak
    mv libdl.so.2 libdl.so.2.bak

Then in one of your two sash shells, try an "exec bash". It will tell 
you that the file wasn't found, and it will exit sash.

I know it's obvious, but I feel obliged to point out that this experiment
simulates catastrophic failure, and can cause unpleasant things to happen
to servers and users on your system. Do it with care, and at an 
appropriate time. If your system is the least bit unhealthy to begin
with, this can crash it down.

At any rate--your suggestion got me thinking, and there MAY be other 
possibilities here. All of them involve trade-offs:

  #1-- sash could try harder to ensure that an "exec" succeeds before
       it allows itself to exit. for example, instead of exec, it could
       fork and exec, and then look for signs the new process was 
       healthy before quitting. 

  #2-- sash could stick around after an exec, and not actually exec at 
       all. it would quit if the exec'd process exits with a normal 
       error return, but it would reapper if the exec'd process exits
       with an error for some reason. this could have subtle implications
       which haven't occurred to me

  #3-- instead of modifying sash, just run bash in your sash startup 
       script and check the return value yourself

The first one has the downside of increasing the complexity between you
and a working root shell. This would have to be pretty heavily tested 
before you'd want it on a production system.

The second and third have the downside of consuming extra memory for 
sash (though it should be shared if you load it twice). So logging 
in as root will cost 300k more than logging in as another user, or so,
but only for root's first login (after which the 300k is shared).

If the above don't work then I think the cloned root user with a disabled
password and a bash shell should be created. Anyone who wants to have it 
can enable the password, and by so doing, take responsibility for the 
security issues.


> Another thing: for all you guys who don't want to automatically set root's
> shell to something else, would it be a reasonable practical solution
> (assuming my other proposal is shot down) to ignore root's shell if set, but
> make sash the default root shell on new systems?  This would follow the
> principle of least surprise, though it might make things pretty hard for
> the new users who don't know what they're doing.

I think this is sensible. You shouldn't change things like this on an 
existing system without at least asking whether it's wanted :-) If the
toor user is created at all, it should always be created, even if 
roots shell is left alone. Just for consistency, and in case the 
admin answered "No" because they needed to fix things up first--then 
later they can switch it manually.

To help new users along, it might be useful to explain what the issues
are when the question is posed.

Justin