Usercreation-policy

[Enrico Scholz]

notting at redhat.com (Bill Nottingham) writes:

> As I'm sure you're aware of, historical Red Hat policy has been
> (watch me forget part of this):
>
> - users are 'registered' when a package wants them, doled out
>   by hand, and recorded in a documentation file.

Yep; but IMO unpractically in the Fedora Project (setup is Fedora Core,
while a lot of users will be created in Extras). And because of the
limited UID-range (0-100) for such UIDs, the pigeon hole principle will
be violated.


>   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?


> - 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.


> 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...


> 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.


> That's actually more than I thought there were, but it's still a
> number that certainly can run out in the future, depending on how big
> the package list explodes.

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


> 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.


> The simplistic proposal is, when necessary, to simply expand
> the range of 'system' users.

Wow---changing the hotloved LSB... Can become an interesting task.



> 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.




Enrico