Re: itp: static bins / resolving static debian issues
On Sun, Aug 22, 1999 at 01:13:52AM -0400, Justin Wells wrote:
>
> 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.
Darn it, you're right. The problem is that the execute sequence actually
goes something like call ld-linux.so.2, and tell it to load bash. If
ld-linux.so.2 exists, and nothing else does, then you get:
./bash: error in loading shared libraries: libncurses.so.4: cannot open shared object file: No such file or directory
If ld-linux.so.2 doesn't exist either, then you get the behaviour I
originally described.
This is annoying. It also means that my sulogin fix is useless. Ugh.
However, the sulogin fix isn't needed if we can figure out some way to get
sash to exec bash only if possible, thereby allowing us to set root's shell
to sash without annoying people.
> 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
This is impossible, as sash is totally non-scriptable.
> 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).
This thread seems to attract more than its fair share of overly resource
paranoid people, so I suppose I'd better mention that only about 260k of
that is shared, and another 45k will be used for each shell. Who cares.
However, looking at the problem, it seems that the programming complexity
of solution 2 is basically the same as that of solution 1 (either way,
we fork, one process exec's and the other wait's, the only difference
being that in solution 1 we sleep then do a waitpid whereas in solution
2 we just do a waitpid). For this reason, and since it does save on some
memory, I have a patch to sash-2.1 implementing solution 1 by adding a new
command '-tryexec', which will fork, the child execl()'s, the parent sleeps
for TRYEXEC_SLEEP, and then checks up on the process with waitpid(). If
the process has exited with an error, then we jump back to sash, otherwise,
sash exits, orphaning the child.
The patch should be available at http://www.debian.org/Bugs/db/43/43330.html.
I've tried to be fairly paranoid about checking things, but I'd appreciate
it if you all would check it out and look for ways that it could break
and leave root without a shell.
> 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
-- Nathaniel
Reply to: