* Nathaniel Smith said:
> First, the security: while it may be theoretically possible to put wrappers
> around passwd and so on, ensuring that the two accounts are kept in sync is
[snip]
> exists at all. This of course might be an acceptable cost if it gained us
> a great deal, but I maintain that it does not.
Well, as Justin has noted that extra account may be disabled. And only the
administrator who a) wants to use it, b) is conscious of all the extra
effort would enable it.
> It is not too difficult, and much less scary from a security standpoint, to
> set things up so that when root logs in, if bash is for some reason
> unavailable, things fall back on sash. Off the top of my head, here are two
> possible ways to implement this:
>
> 1) add to sash the ability to parse a ~/.sash_profile on startup. In that
> file put the line "exec /bin/bash". If bash is broken, the exec will fail
> and leave you in sash (I just tested this, using chroot to simulate
> deleting my shared libraries).
No, it won;t work. A quick look at sash code shows that it doesn't use
fork(2) but directly execvp(3). It means that there's no way to go back to
the shell prompt. I suggested a way to do what you want to do by using a
wrapper program that would try to execute the standard shell and, should
that fail, fallback to sash. I thought it might be something along the
lines (in pseudo code):
pid_t child = fork();
if (!child) {
duplicate_std_streams();
exec*(path_to_bash,...);
_exit(NO_BASH_AVAILABLE);
} else if (child > 0) {
sleep(2); /* should be more than enough */
if (file_exists("/proc/%d/cmdline", child))
exit(0); /* assuming bash is well and running */
duplicate_std_streams();
exec_alternative_shell();
} else {
printf("OOPS: %s\n", strerror(errno));
exit(1);
}
Now, that wrapper would be statically linked and would quietly exec whatever
shell is working.
marek
Attachment:
pgpyYkHFHVGch.pgp
Description: PGP signature