Usercreation-policy

[Enrico Scholz]

notting at redhat.com (Bill Nottingham) writes:

>> > - 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 || :
>> ...
>> A case for bugzilla?
>
> Yes.

Ok, does this mean that the Fedora Project has a packaging guideline:

| A package MUST NOT delete users or groups in its scriptlets

I agree with that, although it violates somehow the idea behind rpm
(there is the same state after a 'rpm -U ...; rpm -e ...' transaction).


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

It makes things easier; and when using a central user/group-registry I
do not know reasons why not to enforce uid==gid. It is similarly to
udp/tcp portnumbers in /etc/services.

I think too, that most daemons need both a dedicated user and a dedicated
group.


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

Not possible; one packaging rule of the (old) Fedora Linux Project was

| 15. Does the package ship daemons or similar programs which support
|     execution as non-root? It is a packaging-error when the daemon runs
|     as root, or as a standard user like nobody. Instead of, a special
|     user must be used;...
|     [http://www.fedora.us/wiki/QAChecklist]



>> > - the IDs still will not be constant across systems; 
>> 
>> With a central configuration management (e.g. cfengine), the UID will be
>> unique.
>> ...
>> 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.)

This is a bootstrap problem. Base-packages (Fedora Core) should have
static UIDs. Then, the administrator can do the basuid/gid customization
and install the Fedora Extras packages which are having the described
semi-static UIDs.

On my (physical) systems, I am using kickstart to setup a minimal system,
call then 'cfagent' in the %post script which copies baseuid. Similarly
when creating vservers; there will be installed some core-packages, then
'cfagent' be called and then the system-dependent packages be installed.


There could be

| Requires: setup(fedora-usermgmt)

also in the fedora-usermgmt package (this, which has the fedora-useradd
script). Then, the administrator can create a package with

| Provides: setup(fedora-usermgmt)

and the customized /etc/fedora/usermgmt/base{uid,gid} files. When copying
such a package into the install-tree and replacing the default one, the
customization could happen at install-time.


When there is some agreement on this, I will split fedora-usermgmt in
the described way.


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

'dynamically allocation' means for me, 'useradd -r' which uses a random
free UID-slot.

Using static UIDs between 100 and 500 for Fedora Extras packages will
break update of existing systems, since those UIDs can be assigned there
already. So you can not simply expand the range of 'system' users.

With my baseuid approach the administrator could choose a free area and
put a fitting value into /etc/fedora/usermgmt/baseuid before doing the
update.


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

Ok; can be done with cfengine also:

| links:
|    ./scripts.shadow-utils ->! /etc/fedora/usermgmt/scripts




Enrico