Native sysusers support is missing dependencies

[keszybz]

Please correct me if I got something wrong. My understanding is the following:

• rpmbuild will generate Provides: user(foo) = <hash> and Provides: group(foo) = <hash> (??, see below) for packages which have sysusers.d files
• rpmbuild will generate Requires: {user,group}(foo) or Recommends: {user,group}(foo) for packages which carry files owned by user or group foo (depending on %_use_weak_usergroup_deps)
• rpm carries /usr/lib/rpm/sysusers.sh and will invoke it when installing packages which have the appropriate Provides.
• sysusers.sh is in bash (provided by bash.rpm) and calls useradd, groupadd, usermod, groupmod (provided by shadow-utils.rpm), touch, cut, mkdir (provided by coreutils.rpm), and grep (provided by grep.rpm).
• rpm.rpm declares dependency on bash and coreutils, but not grep or shadow-utils
• sysusers.sh implements u, g, and m, but not r
• sysusers.sh knows about /usr/lib/sysusers.d, /run/sysusers.d, and /etc/sysusers.d, but not about /usr/local/lib/sysusers.d.
• sysusers.sh also doesn't know about specifiers

The lack of dependencies seems to be a problem. A package may have Requires: user(foo), which will pull in some package that has Provides: user(foo), but this is not enough. Something else needs to pull in both rpm and shadow-utils and grep.

Those tool dependencies are a problem: rpm is a very big dependency. It is strange to install it in images just to create users. Maybe it should be split out to rpm-sysusers-impl (name TBD), so it can be installed without the rest of the stack? Also, that package should probably get dependencies on the appropriate tools.

Packages which are supposed to provide a user should get a Requires or Recommends dependency on the implementing tool (depending on %_use_weak_usergroup_deps).

I understand the decision to move away from systemd-sysusers as the implementation, but it would be great if it was still allowed as an option. In fact, systemd provides two implementations: one in systemd.rpm and the second one in systemd-standalone-sysusers. The latter has dependencies only on glibc, libcap, libgcc, libselinux, and libgcrypt, and is much smaller than shadow-utils.

For example, packages that have Provides: {user,group}(…), could have a dependency on rpm-sysusers-impl | systemd-sysusers, and rpm should attempt to call both systemd-sysusers and sysusers.sh.

Please explain how this is all supposed to be integrated by a distro…

---

I was testing this with dbus package, and I noticed the following:

• dbus-common has Provides: user(dbus) = dSBkYnVzIDgxICJTeXN0ZW0gTWVzc2FnZSBCdXMiIC0gLQAA but Provides: group(dbus), with no = …. Looking at the code, this provides will be ignored. Is this intentional?
• I can't get this to work at all. After calling sudo dnf5 install --use-host-config --installroot=/var/tmp/inst5 noarch/dbus-common-1.14.10-1.fc40.noarch.rpm I get no dbus in /var/tmp/inst5/etc/{group,passwd}. I tried installing rpm, grep, shadow-utils and part of the same transaction, or in an earlier transaction, and the result is the same.

/cc @DaanDeMeyer

[pmatilai]

Didn't look through this all just now, but a couple of quick notes:

• The sysusers support is disabled in the Fedora package, you need to uncomment %__systemd_sysusers in the main macros file
• The sysusers addition runs from outside a chroot, so the "host" provides all the dependencies. That's basically the only way an empty chroot can be bootstrapped with file ownerships from the first package. In other words, you're overthinking it all by a mile. It's of course possible the main rpm is missing some packages for the script-based sysusers.sh version (and should be added explicitly), but grep, shadow-utils and all that are almost certainly pulled in by something else that rpm depends on. That's a Fedora packaging matter though.
• The dbus user vs group EVR thing is explained in https://rpm-software-management.github.io/rpm/manual/users_and_groups.html the technical details section but in short: sysusers creates implicit groups for all users, so the group doesn't need any more info. The provides is there only for dependency resolution.

[pmatilai]

Please explain how this is all supposed to be integrated by a distro…

I did just that in this fedora-devel post from June: https://lists.fedoraproject.org/archives/list/[email protected]/message/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/

It doesn't talk anything about shadow-utils and such tooling dependencies because for all practical purposes there are none. You just don't need to care.

I understand the decision to move away from systemd-sysusers as the implementation, but it would be great if it was still allowed as an option.

Just point %__systemd_sysusers to the binary/script that you want to handle it. The implementation is entirely selectable, and native systemd-sysusers is the interface that it actually follows.

[pmatilai]

Oh and of course, it is all very very different from what user/group handling in rpm has traditionally been. You need to just unlearn that all 😄

The key difference really is that with the sysuser integration, the rpm running the transaction is what does the work and contains any tooling dependencies, whereas in the traditional model it's the packageset being installed that get to do the work. So instead of adding more shadow-utils deps and the like, you instead get to remove those deps from the packages. And, like said, you can now have arbitrary users starting from the very first package being installed because the user/group tooling doesn't need to be bootstrapped first in that environment.

[pmatilai]

(moved to discussions as this is more like a pile of questions than an issue)