This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
This proposal consists of two parts. The first is to make sure that rpm functionality is fully enabled in Fedora. The second is to update packaging guidelines and raise awareness about the new simpler user creation method for rpm packages. The goal is a fully declarative system user and group management in all RPMs. Over time we should be able to drop all manual useradd/groupadd invocations or use of %sysusers_create_compat macro in rpm scriptlets.
Support for sysusers was added in rpm 4.19.0. Support for group membership (m lines) was added in rpm 4.20.0. Support for locked-down users (u! lines) was added for rpm 4.21.0. The rpm package has patches to disable user/group creation (rpm-4.18.92-disable-sysusers.patch) and make user/group dependencies weak (rpm-4.19.91-weak-user-group.patch).
Feedback
Discussion about idea to submit the proposal on fedora-devel list.
Benefit to Fedora
Declarative system user and group management by packages
Potential for spec file simplification, concretely, removal of relevant part of %pre scripts in some packages.
Ability to query what user and groups are provided by given package as well as ability to have dependencies on users/groups from different packages.
Make use of native rpm functionality in favor of current %sysusers_compat_create.
Scope
Proposal owners:
Change rpm so that it generates hard dependency between packages A and B in case B depends on user or group provided by package A. Rpm currently has downstream patch so that only weak dependencies are generated.
Make sure that previous change in rpm doesn’t cause package dependency loops during system installation.
Work on fix for shadow-utils so that useradd and groupadd work correctly in chroot on SELinux enabled systems (shadow-utils issue.)
Other developers:
We would welcome any help with shadow-utils issue.
Release engineering: N/A (not needed for this Change)
Policies and guidelines: N/A (not needed for this Change)
Trademark approval: N/A (not needed for this Change)
Alignment with the Fedora Strategy:
Upgrade/compatibility impact
There is no upgrade/compatibility impact.
How To Test
Select rpm package that creates system user/group account in %pre
Remove part of %pre scriptlet that handles user/group creation
Create equivalent sysusers.d configuration file and ship it as part of rpm payload under /usr/lib/sysusers.d/.
Rebuild the package
Verify that package has been built correctly and it has rpm provides for installed user account and group (e.g. user(foo) = ABUNCHOFHEXHERE, group(bar) = ADIFFERNTBUNCHOFHEXHERE). Use rpm -qP $package | awk '/(user|group)\(/ {print $3}' | base64 -d and check that the output looks reasonable.
Verify that you can install the package and installed files have correct ownership.
User Experience
There shouldn’t be any user observable change to previous state. Potential packaging related benefits are mostly of interest to package maintainers.
Dependencies
None
Contingency Plan
Contingency mechanism: If we are not confident by mass-rebuild that we can deliver the feature we will postpone its delivery to later Fedora release. There are no explicit rollback/cleanup actions that need to taken.
Contingency deadline: Mass Rebuild of RPMs on Wed 2025-01-15.
If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.
We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.
Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.
I’m slightly confused here. RPM 4.21 is not a thing (at least not yet), the current latest release is 4.20 and AFAIK the next release will jump to 6.0.
I wrote “for 4.21”. The idea is that it was merged into the main branch and will be part of the next release, whatever its number. I’ll edit the wiki page to say “next release”.
With rpm versions that support sysusers.d you can simply do rpm -q --qf "[%{SYSUSERS}\n]" $package. The sysusers tag extension is literally how rpm itself decodes the information during installation.
Some more thoughts as the vacation haze is clearing out
The entire distro has already been built at least a couple of times with rpm >= 4.19 so all the relevant dependency info is already there. So, anybody wanting to try it out can easily test the install-time functionality already: just uncomment the %__systemd_sysusers line in /usr/lib/rpm/macros.
The catch is that in presence of dependency loops, install ordering will behave differently wrt weak/strong dependencies, so once the distro is rebuilt with user/group dependencies as hard requires (which they are by nature), it’s possible some loop-tangle that happens to currently work could start exhibiting some new issues, but those would basically be already existing packaging issues just been lucky so far. As always, the way to address dependency loops is to analyze and cut them, not by adding Requires(pre-me-more) and hope for the best.
I’ve been running my Fedora 40-41 laptop with sysusers enabled in rpm for a few months now, with no noticeable issues except for the chroot install problem due to the shadow-utils thing. chroot installs actually still work because sysusers failing causes the user/groupadd in the regular scriptlets to kick in, but the errors are ugly-scary. You can get around that by pointing %__systemd_sysusers to native systemd-sysusers instead (that’s how the feature was originally developed), the caveat with that is that last I looked it didn’t create the audit events Fedora/RHEL requires. So adding the (allegedly) missing audit events to sysusers-systemd and switching to that would be an alternative path for addressing the chroot/selinux issue in shadow-utils.
Yup, noticed. I’ve a PR prepared for enabling the hard user/group dependencies but just then something in the Fedora infra went belly-up (getting Fatal error (500) trying to log in and Pagure too) I’ll push that once the incident is cleared.
So, somehow I was under the impression most of Fedora is already using the sysusers.d based user creation. I don’t know where I got that idea, but looking closer there’s a wild number of packages still using good old manual useradd/usergroup. And each of those is broken by the hard user/group dependencies.
I’m reverting the hard user/group dependencies patch now, this isn’t going to fly. We’ll need to address those manual useradd/groupadd packages first: either (preferably) move them to sysusers or add manual provides where that’s not feasible for one reason or another. And given the number of affected packages, it’s not a walk in the park.
Summary
instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.
(getting Fatal error (500) trying to log in and Pagure too) I’ll push that once the incident is cleared.