Users and Groups

Rpm >= 4.19 has native support for declarative user and group creation through integration with systemd’s sysusers.d format. Packagers will only need to package a sysusers.d file for their custom users and groups in /usr/lib/sysusers.d and rpm will take care of the rest.

It’s also possible to declare sysusers.d entries manually with %add_sysuser macro in the context of the (sub-)package. The macro simply takes a sysusers.d line as arguments, such as %add_sysuser g mygroup 515. Using this method is not recommended on native systemd distributions.

Note that for certain types of systemd services (eg. transient and socket activated services) it may be possible to avoid package level user/group allocation altogether by using dynamic users.

Dependencies

Any non-root ownership in %files section (through %attr() or %defattr()) generates an automatic dependency on the named user and/or group. Similarly, packaged sysusers.d files create provides for the users and/or groups they create. This ensures correct installation when a package relies on user/group from another package.

Explict group membership (m) will also create a dependency on both the user and the group name.

By default the dependencies are hard requirements, but as this can be problematic when upgrading an existing distribution to rpm 4.19, it’s possible to weaken these into recommends-dependencies by setting %_use_weak_usergroup_deps macro to 1 during package builds.

Limitations

At this time, rpm only supports the u, g, (since RPM 4.20) m and (since RPM 6.0) the u! directives of sysusers.d format and ignores others. If other directives are needed, the package will need to call systemd-sysusers with the correct arguments manually.

Technical details

As the sysusers.d data is needed before it’s unpacked from the payload during installation, rpm encodes the relevant parts into the EVR string of generated user() and group() provides: the sysusers.d line is base64 encoded, with the input \0-padded as needed to avoid base64 ‘=’ padding in the output, which would be illegal in the EVR string. These are decoded and fed into systemd-sysusers during installation, passing --replace <path> and --root <path> as appropriate.

For example, the following sysusers.d line:

u dnsmasq - "Dnsmasq DHCP and DNS server" /var/lib/dnsmasq

…emits the following provides attached to the originating file:

user(dnsmasq) = dSBkbnNtYXNxIC0gIkRuc21hc3EgREhDUCBhbmQgRE5TIHNlcnZlciIgL3Zhci9saWIvZG5zbWFzcQAA
group(dnsmasq)

As systemd-sysusers implicitly creates a matching group for any created users, the group provide does not have an EVR here, only explicitly created groups will have the encoded sysusers.d line as EVR.

Lines adding users to groups like

m klangd klong

will create a provide:

groupmember(klangd/klong) = bSBrbGFuZ2Qga2xvbmcA

but also create two requires (or recommends if the _use_weak_usergroup_deps is set to 1):

group(klong)
user(klangd)

to make sure the packages creating the user and the group are install first.

Implementation

RPM by default does not actually use systemd-sysusers, but has its own shell script (sysusers.sh) that calls useradd and groupadd. The program to call can be configured with the %__systemd_sysusers macro. It is possible to point it to the systemd-sysusers utility, but it may be undesired to add this as a dependency to RPM. systemd-sysusers is normally installed as part of the main systemd package, but in installations (for example containers) where systemd is not needed, the smaller systemd-standalone-sysusers package which does not pull in the rest of systemd may be used.

On systems that do neither have useradd and groupadd nor one of the systemd packages, a custom script or program can be used. Such a script needs to read sysusers.d lines from the standard input and then call the native user and group creation tools as appropriate. The script needs to handle --root <path> argument for chroot installations - the script runs from outside of any possible chroot, and care must be taken to avoid changing the host in such a case.