(→Detailed Description: add description of separate packages) |
(→Detailed Description: add info about arch) |
||
Line 59: | Line 59: | ||
This approach is heavily based on OpenSUSE's ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups guidelines]), including the naming of separate package and virtual Provides, but does not mandate separate rpm packages. I think using a %pre macro is good enough for the majority of cases. In the case when the user or group is needed by multiple independent packages (for example different implementations of a web service), the sysusers.d file may be split out to a separate rpm subpackage called <code>system-user-<name></code>. This package may then be pulled in using <code>Requires(pre): user(<name>)</code> or <code>Requires(pre): group(<name>)</code>. | This approach is heavily based on OpenSUSE's ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups guidelines]), including the naming of separate package and virtual Provides, but does not mandate separate rpm packages. I think using a %pre macro is good enough for the majority of cases. In the case when the user or group is needed by multiple independent packages (for example different implementations of a web service), the sysusers.d file may be split out to a separate rpm subpackage called <code>system-user-<name></code>. This package may then be pulled in using <code>Requires(pre): user(<name>)</code> or <code>Requires(pre): group(<name>)</code>. | ||
Note: arch linux also uses sysusers in a similar fashion: packages may include a sysusers.d file, and a hook runs sysusers whenever such a file is installed, see [https://git.archlinux.org/svntogit/packages.git/tree/trunk/20-systemd-sysusers.hook?h=packages/systemd sysusers.hook]. | |||
== Benefit to Fedora == | == Benefit to Fedora == |
Revision as of 12:43, 5 January 2020
Adopting sysusers.d format
Summary
Files in sysusers.d format will be used to declare systems users so it will be possible to introspect system users. Users will still be created using old-style useradd calls.
Owner
- Name: Zbigniew Jędrzejewski-Szmek
- Email: zbyszek at in waw pl
Current status
- Targeted release: Fedora 32
- Last updated: 2020-01-05
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Many packages define their own user. Right now, those users are created in %pre by calling getent, useradd, and groupadd (guidelines). This will be changed to define users in the sysusers.d format. A macro will be provided to generate a %pre scriptlet that will call useradd and groupadd similarly to the scriptlets that are currently required by the packaging guidelines. An rpm Provides generator will be added to generate user(<name>)
and group(<name>)
virtual Provides for packages with sysusers.d files.
In this proposal, systemd-sysusers will not be used to created the user. Using the sysusers.d format makes it easy to switch to systemd-sysusers as the implementation, and to experiment with different way to actually create the users based on the declarative syntax.
This approach is heavily based on OpenSUSE's (guidelines), including the naming of separate package and virtual Provides, but does not mandate separate rpm packages. I think using a %pre macro is good enough for the majority of cases. In the case when the user or group is needed by multiple independent packages (for example different implementations of a web service), the sysusers.d file may be split out to a separate rpm subpackage called system-user-<name>
. This package may then be pulled in using Requires(pre): user(<name>)
or Requires(pre): group(<name>)
.
Note: arch linux also uses sysusers in a similar fashion: packages may include a sysusers.d file, and a hook runs sysusers whenever such a file is installed, see sysusers.hook.
Benefit to Fedora
System users are declared by packages using a uniform syntax.
The scriptlet part is standarized. Current implementation of creating users and groups is not changed, but may be switched easily in the future. For example, for container images, the macro may be replaced by a noop implementation, and the users created externally without installing the user creation tools in the container.
Admins may easily introspect the system user list and which packages require users.
Admins may easily override definitions of system users by providing appropriate sysusers.d files with higher priority.
The difference between Fedora and other distros like OpenSUSE is reduced.
Scope
- Proposal owners:
- provide the macro and any helper tools
- submit a proposal to FPC
- convert a subset of packages
- Other developers:
- FPC: review (and accept ;)) the guidelines changes
- other maintainers: convert other packages
- Release engineering: n/a
- Policies and guidelines: a pull request will be submitted
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
None. This change should be backwards and forwards compatible, i.e. unconverted packages can be still installed on new systems, and converted packages can be installed on older systems.
How To Test
This change should be mostly invisible to users. During installation, users should be created as appropriate before packages are installed. For packages that carry files owned by the user, check that the files are created with appropriate ownership by rpm.
User Experience
systemd-analyze cat-config sysusers.d/
shows the definitions of system users (incl. local overrides).
Dependencies
N/A
Contingency Plan
- Contingency mechanism: Revert to previous mechanism. This will require a revert of changes to the spec file and a rebuild of the package.
- Contingency deadline: beta freeze
- Blocks release? No
- Blocks product? No
Documentation
TBD.
Release Notes
Not needed.