Usercreation-policy

[Bill Nottingham]

Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: 
> >   This is currently in the setup package, uidgid file.
> > - users and groups are *not* deleted on package uninstall; as they're
> >   unique, that's not a big of a deal.
> 
> | $ rpm -q --scripts postgresql-server
> | postuninstall scriptlet (using /bin/sh):
> | ...
> |       userdel postgres >/dev/null 2>&1 || :
> 
> Same for named, wnn, pvm, rpm, radvd, nscd, rpcuser, nfsnobody, xfs,
> canna.
> 
> A case for bugzilla?

Yes. While the fact that they're not reused should lower the
risk of problems, it's certainly safer to leave them allocated.

> > - users and groups are *not* reused. Even if the old package goes
> >   away.
> 
> With dynamic creation, they *are* reused. The current 'useradd -r'
> implemention uses low UIDs (<100) also, when UID 499 is in use.

Cute. Another one for bugzilla.

> > As for what's doled out, the id ranges in the system are:
> >
> > - 0-100 - system users
> > - 101-499 - reserved for local sysadmin use
> > - 500+ - useradd starts adding users here
> 
> Yep; braindead LSB requirements...

LSB had an originally stated goal of codifying existing practice
(as opposed to defining new behavior)... so if X distros did it that
way, that was probably what the spec would be.

> > Obviously, limiting things to <= 100 makes things somewhat crowded.
> > Currently, there are 44 UIDs and 32 GIDs free, unless I missed one.
> 
> Oh yes, I just did a 'wc' on it and come to 71 UIDs therefore. But I
> would enforce that for each user a group with the same name and GID
> shall be created (and vice versa). So you are coming somewhere into the
> area of 70 reserved slots.

Ah, see, I don't see that as completely necessary. Matching is nice,
but it can be worked around.

> Nearly all of my server-packages (lots are unpublished) are creating
> special users so that I will need around 15-20 UIDs ;)

Obviously you should stop using so many. :)

> > One issue with the proposal as mentioned:
> >
> > - the IDs still will not be constant across systems; it will still run
> >   into the filesystem sharing issue as mentioned on your dynamic user
> >   page; if the different systems choose a different base, they'll get
> >   different IDs
> 
> With a central configuration management (e.g. cfengine), the UID will be
> unique. E.g. you can
> 
> | copy:
> |   ..../baseuid   dest=/etc/fedora/usermgmt/baseuid ...
> 
> and all your machines will use the same base for the relative UIDs.
> 
> The administrator can set the value in baseuid accordingly the local
> system policies.

Sure, there are distribution mechanisms (cfengine, rdist, rsync,
whatever-you-like) to keep such files in sync. It's still not
universially applicable (i.e., *competely* static is obviously
preferred.)

> > The simplistic proposal is, when necessary, to simply expand
> > the range of 'system' users.
> 
> Wow---changing the hotloved LSB... Can become an interesting task.

It's allowable by the draft spec:

The system UIDs from 100 to 499 should be reserved for dynamically allocation
by system administrators and post install scripts using useradd(1).

> > Obviously, anything you do here is going to run into established practice
> > somewhere,
> 
> My fedora-usermgmt package defaults in the current version to the legacy
> method (ignore the semi-static UID). With 'alternative' magic, honoring
> of the baseuid file can be enabled.

alternatives. Ick.

Bill