Usercreation-policy
Bill Nottingham
notting at redhat.com
Wed Sep 24 03:51:49 UTC 2003
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
More information about the devel
mailing list