Subject: Re: Changing root's shell to /bin/sh
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 03/17/1999 22:11:02
[ On Wednesday, March 17, 1999 at 20:31:48 (+0100), Soren S. Jorvang wrote: ]
> Subject: Re: Changing root's shell to /bin/sh
> As I see it, having [the ability to have] more than one user
> profile per uid is a hack/artifact of the way the traditional
> password database implementation and the world would be a
> simpler place without it.
Well, it's a "unix" kind of hack, i.e. one with enough rope....
> Having two root accounts is just asking for confusion.
and when there's confusion over a superuser account then there's a
security risk too....
Either you allow duplicate superusers, or you don't. K.I.S.S.,
especially when it comes to security-critical policy.
In fact unless your "application" was specifically designed to work with
duplicate uids (or has some design flaw that requires such nonsense)
then any duplicate use of uids is "risky".
> Also, while I think /bin/sh would be more suitable as the
> default root shell, a better generalization would perhaps
> be to have init make a relaxed attempt at finding root's
> shell from /etc/passwd and offer that when booting in
> single-user mode?
That'd be OK with me so long as lots and lots of people made a point of
taking a good hard look through the new code to make sure it was
reliably and well written....
> To add a perhaps more useful little suggestion, how about moving
> users ingres and falken below uid 100?
That's really a matter of conventions, and I'd just as soon see some
general guidelines written down (eg. in the manner of hier(7)) before
any changes are made.
For example I usually use the following "categories":
1-9 - critically important system id's
10-99 - base-os subsystem UIDs (mail, uucp, printing, etc.)
100-399 - application specific UIDs
400-499 - FTP server accounts (ftp == 400 for annonymous)
500-999 - UUCP accounts (500 == nuucp for annonymous)
1000-* - user accounts (may have sub-"categories")
While we're at it, how about removing the mostly bogus and somewhat
risky limitation of not allowing a uid of 4294967294? As I've mentioned
before this is in conflict with the default use of "-2" in mountd for
NFS' root uid & gid map (well, in conflict so far as being able to put a
user-id in the passwd file to describe this magical "-2" user).
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>