[ On Thu, December 31, 1998 at 09:40:58 (+0100), Marc Baudoin wrote: ]
> Subject: Re: Minor /etc/security problems
>
> Curt Sampson <cjs@cynic.net> =E9crit :
> >=20
> > Well, what is most important to me is just to have a standard set
> > of UIDs and passwd entries for all this stuff. It doesn't have to
> > be in the master.passwd file as shipped. What about reserving all
> > IDs below 100, and shipping a separate file that contains master.pa=
sswd
> > entries for these IDs?
>=20
> Yes!  And don't forget the gids, which should follow the same
> conventions.  Ideally an uid should have a corresponding gid with
> the same number (which is not the case today for ingres, uid 267
> gid 74, which I find awkward).

This whole discussion is hilarious.

In Unix there's only *one* user-ID and *one* group-ID that truely
matters, and only a very few that need to be used in the system
distribution (and only then to avoid the "chicken & egg" extraction
problem, especially given that the existing distribution format only
stores the numeric user-ID and group-ID -- this problem could be avoide=
d
after extraction by running mtree, but that's risky).  Everything else
is a matter of local taste.  The ones that matter are, of course, those=

with values of zero(0) (i.e. "root" and "wheel" as they are normally
called).

IMNSHO the ones used in the distribution should be kept as they are
except that there should be no additional "unnecessary" entries in the
standard disributed passwd or group files.

For very simplistic binary distribution schemes there can be that same
"chicken & egg" problem, but so far as I can tell pkg system can totall=
y
avoid this issue (at least so long as all packages that need to include=

mtree files and nobody uses the "gid" or "uid" keywords instead of
"gname" and "uname".  Please let's not live too far in the past with
this, especially when we have the tools to fix it now.

What might be nice is a collected set of wisdom and folklore that could=

be put in adduser(8) and the SMM to help new admins figure out some
nifty schemes for organizing their UID and GID assignment plans.  It
might also be nice if there were some simple scheme other than NIS
integrated into the standard NetBSD distribution to help admins assist
in synchronising their base master.passwd and group files, especially t=
o
new machines (though I don't have any suggestions I'm really happy with=

yet).  Making the UMAP filesystem production quality might also help
(such as the ability to use a live pwd.db file to specify the mapping
for the remote filesystem!).

Nothing fancy (in terms of comming up with extended and detailed
"standardisation" of UIDs and GIDs) is ever going to meet the needs of
everyone, and too much detail may actually cause some people to have to=

do extra work to undo things.

> - real system accounts (like root, daemon, operator and bin),
>   should have uid < 10 and a consistent corresponding gid (why
>   operator is uid 2 and group 20, bin uid 3 and gid 7?  Some kind
>   of historic reason?  Also why is there a nobody group with gid
>   39 instead of 32766?)

What's totally silly is that the default "nobody" mapping done by mount=
d
is *still*, after all these years, hard-coded to "-2:-2", which with
uid_t and gid_t being defined as u_int32_t, this means the master.passw=
d
entry should be something like:

    nobody:*:4294967294:4294967294::0:0:NFS Unprivileged User::/sbin/no=
login

Unfortunately UID_MAX and GID_MAX are not 4294967294, so pwd_mkdb blows=

up in your face if you try this.

The ideal solution to the NFS "nobody" ID choice is to make UID_MAX and=

GID_MAX be equal to 0xffffffffU (i.e. UINT_MAX where an unsigned int is=

32 bits) *AND* to make parsecred() in mountd.c look up the passwd file
entry for "nobody" and use that UID/GID instead of defaulting to
"-2:-2", *AND* to add advice to exports(5) that always recommends using=

"-maproot=3Dnobody" for all exported "filesystems" that are used by
machines who's superusers cannot be trusted.  [[ The idea here is, of
course, that on a properly configured NFS server no non-world-writable
file should ever be owned by the "nobody" UID or GID, which is somethin=
g
/etc/security should really check for too. ]]

(Similar problems may exist in the experimental umap filesystem too.)

> - other non essential system accounts (games, mail, news, www,
>   database, whatever) should have uid and gid >=3D 10 and < 100,
>   which should leave enough room.

It would be *nice* if the distributed master.passwd and group files did=

not contain any UIDs or GIDs outside the range 0-100.

BTW:  HAPPY NEW YEAR to everyone!  (even though I've got the better par=
t
of an hour more to go, I'd guess the majority of the world's population=

is already in 1999 ;-)

--=20
=09=09=09=09=09=09=09Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>=

Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>=