English Finnish
Users and Groups Guidelines
This guideline is for packaging cases that require creation of users and groups.
Basic premise for users
In designing these guidelines it was accepted that individual sites will have a need to customize the allocation of UIDs and GIDs to their particular systems. For instance, if they have both Debian and Fedora installs or if they've already allocated user accounts in the range that we use for system accounts and need to place system accounts elsewhere. Therefore, the methods that these guidelines advocate had to be adaptable so that local sysadmins could make our packages use the UIDs and GIDs that they desired at their site.
The guidelines provide two options: letting each individual system allocate UID and GID values individually or using a "soft static" allocation that attempts to allocate UIDs and GIDs consistently. In either case, if the username or groupname being created by the package already exists on the system the package will use that instead of creating a new one. This allows the local system administrator to pre-allocate the UIDs and GIDs for particular usernames and groupnames in order to set them to a particular value for their site.
Methods of pre-allocating
There are many ways to pre-allocate the UIDs and GIDs. Sites that only want to customize the UIDs and GIDs of a few nonessential services may write a script to create the entries with `+useradd+` and `+groupadd+` and install our package afterwards.
Sites that want to pre-allocate accounts that are needed during an unattended kickstart install have trickier problem. One way for them to accomplish their goals is to create a customized version of the "`+setup+`" package with the desired users and groups along with their chosen UID/GID mappings in the `+/etc/passwd+`, `+/etc/shadow+`, and `+/etc/group+` files. Then they make sure the install transaction uses that package instead of the vanilla distro one (by versioning their setup package higher than ours (for instance, with an epoch) and putting it in a local repo they include when installing or replacing our setup package with their own in a local mirror of the packages that they are installing from). Since setup is at the top of the dependency tree, it will be installed before any package which needs to use the UIDs and GIDs that are defined in it.
*Using LDAP to preallocate*:
Sites with LDAP or other network authentication systems
may want to use those for pre-allocating their system accounts sitewide.
Such sites should make sure their infrastructure is robust
and includes suitable local caching of the system accounts.
Without suitable local caching,
a computer that becomes disconnected from the network
may not be able to start essential services
because the computer is unable to resolve a username or groupname
to a proper UID or GID.
Known caveat of the pre-allocation strategy
The practice of using existing users and groups if their symbolic names (usernames and groupnames) already exists on the system lets the system administrator customize the UIDs and GIDs as they please. However, it has one drawback that system admins should be aware of. If an unrelated account has already been created that uses those usernames and groupnames the package will make use of those accounts.
As an example, say that you are installing the mailman package which wants to create the `+mailman+` user and group so that the private mailing list archives can be owned by that user and group on disk. One of your local users already has the local username `+mailman+`. When the mailman package is installed, it will detect that there is already a `+mailman+` user and use that account for owning its private archives. The local user who owns the mailman account would then be able to read those private archives.
At the moment, there is no strategy for the packagers to counteract this. It is up to the site system administrators to keep track of and remove conflicts for the user and group names used by their users and those used by the packages they are using.
Allocation Strategies
We have two methods for creating users and groups: Dynamic and Soft Static.
Any package can use dynamic allocation; it is especially appropriate for packages that use separate identities only for privilege separation and don't create any files owned by that group/user account. Because of the limited number of soft static UIDs and GIDs available, it is better to use dynamic allocation if in doubt.
Soft static allocation ensures that multiple independently installed systems use the same UID and GID values; either UID and GID values allocated by Fedora or values that were optionally pre-allocated by the system administrator. Don't use soft static allocation unnecessarily as the number of available values is limited. Soft static allocation is only appropriate for packages where the UID or GID values are shared between computers. For instance, if the package creates files with the assigned UID or GID that are likely to be shared over NFS. Soft static allocation *MUST* be evaluated by the FPC. See the paragraph in the link:#_soft_static_allocation[ soft static section] for details the FPC will want.
In some cases it is desirable to create only a group without a user account. Usually this is because there are some system resources to which we want to control access by using that group and a separate user account would add no value. Examples of common such cases include (but are not limited to) games whose executables are setgid for the purpose of sharing high score files or the like, and/or software that needs exceptional permissions to some hardware devices and it wouldn't be appropriate to grant those to all system users nor even only those logged in on the console. In these cases, apply only the `+groupadd+` parts of the below recipes.
Dynamic allocation
To create users and groups in packages using dynamic allocation, do the following: