docs/users-and-groups: expand on static users and systemd-sysusers

[jmarrero]

https://docs.fedoraproject.org/en-US/bootc/authentication/ links to this page instead of copying the info, so we should be OK. This doc is 99% Colin's modifications.

[cgwalters]

cc @keszybz

[cgwalters]

Typo here "a on"

[keszybz]

I was later to the review, but here are some comments anyway:

At the time of this writing this relies on SMBIOS which is mainly configurable in local virtualization environments. (qemu).

I don't know when this was written, but nowadays it's quite wrong. There are multiple other mechanisms to pass credentials other than SMBIOS.

It is common for packages (deb/rpm/etc) to allocate system users or groups as part of e.g apt|dnf install <server package
such as Apache or MySQL, and this is often done by directly invoking useradd or groupadd as part of package pre/post installation scripts.

With https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers, this is now not true for dnf install. Distro packages in F43+ do not call useradd or groupadd…

COPY mycustom-user.conf /usr/lib/sysusers.d

We recommend the file to be named after the package. So this probably should be myservice.conf or something like that.

Such cases are best handled by being converted to use sysusers.d (see Fedora change)

Using sysusers.d doesn't really matter or solve anything. systemd-sysusers intentionally implements the same allocation policy, dynamic by default, as the scriptlets specified in the Fedora Packaging Guidelines.

/var/lib/my_file.conf

Extra ".conf" here. We wouldn't have a config file in /var and it doesn't match the snippet below.

--

The big problem with this text is that it doesn't explain the problem adequately, and it doesn't offer a solution that people can select&paste into their own stuff. After doing packaging for a while, I know that if you offer people a menu of low-level options like this, most people will just ignore it, and a few will use it in very creative ways. I think that there needs to be a simple recipe like "If you have this situation, do this, and otherwise, if this, then that, otherwise something else.".

Using tmpfiles to set file ownership during boot is a useful workaround, but it has caveats. One is that systemd-tmpfiles is called during not-too-early boot, so the service that wants to use the files cannot start too early. This shouldn't be a issue for most services though, but might be worth mentioning. Second, bigger, issue is that for this to work reliably the file must be owned by root first, and then chowned to the user/group. If it is owned by the user/group, and drift occurs, it'll be wrongly owned after installation and during early boot and this creates likely confusion and a potential vulnerability. A typical package for which we'd want to use such a tmpfiles snippet, i.e. which has a static owned file in the payload, falls into this trap :(