#850 New useradd/groupadd guidelines
Opened 5 years ago by sgallagh. Modified 5 years ago

In order to get some more transparency in the process, I'm opening this ticket to track the work that @wwoods, @harald and myself are doing to improve the way that we create users and groups in RPM spec files. For the moment, this ticket is informative, not actionable. We want to keep people in the loop (and get feedback), but we will state it clearly in this ticket later when there is something to be voted on.

To summarize the problems we have today (in no particular order):

  • Despite the guidelines, there are numerous different ways that users script the creation of users and groups.
  • Currently, the implementation of user and group creation is reimplemented in every package that requires it. This means that if we want to modify the way it happens, we have to make a mass package change.
  • Creation of users as part of scriptlet execution is problematic for image-generation (such as via Weldr or ostree creation). We need to have a way that we can introspect the SRPM and see what steps we should perform in the image-generation tool. Parsing arbitrary shell scripts is infeasible.

To this end, we are looking to make a one-time mass package update to replace all of the disparate implementations of user-creation with a set of macros that will implement the user and group creation as LUA.

These macros are being designed to be (eventually) multi-purpose; thus they will have a prefix of %osbuild_. This is to leave open the door to using them to handle other common RPM setup activities as well. At present, we're looking at the following macros for use:

  • %osbuild_groupadd [-S subpackagename | -n packagename]: Accepts the same arguments as the groupadd command on the installed system. Stores information in a JSON string for use by the %osbuild_pre, %osbuild_install and %osbuild_files macros later. The -S argument means "This applies to the foo-subpackagename subpackage". The -n argument means "This applies to the packagename package produced from this SRPM". This macro must be specified within the matching %package section.
  • %osbuild_useradd [-S subpackagename | -n packagename]: Accepts the same arguments as the useradd command on the installed system. Stores information in a JSON string for use by the %osbuild_pre, %osbuild_install and %osbuild_files macros later. The -S argument means "This applies to the foo-subpackagename subpackage". The -n argument means "This applies to the packagename package produced from this SRPM". This macro must be specified within the matching %package section.
  • %osbuild_pre [-S subpackagename | -n packagename]: A macro that must be added to the %pre section that will ensure that the appropriate users and groups specified by the %osbuild_useradd and %osbuild_groupadd macros are populated on the target system before files are laid down. The -S and -n arguments are the same as for the useradd and group add macros. This macro must be specified within the matching %pre section.
  • %osbuild_install [-S subpackagename | -n packagename]: A macro that must be added to the %install section that will ensure that the necessary user and group files are installed into the target system. Unlike the other macros, all of the -S and -n variants need to be run in the %install section.
  • %osbuild_files [-S subpackagename | -n packagename]: A macro that expands to the list of files that RPM needs to own that would be installed by %osbuild_install. Each -S and -n invocation must be included under the matching %files section.

A sample specfile in this format can be viewed on Github: https://github.com/fabrix/osbuild/blob/master/test/test.spec

The implementation of these macros is still a work-in-progress, but is viewable at https://github.com/fabrix/osbuild


Metadata Update from @churchyard:
- Issue assigned to sgallagh
- Issue priority set to: None (was: Needs Review)

5 years ago

Thank you @sgallagh. I've assigned the ticket to you to show that there is no action needed from the FPC yet. Thanks for the nice and detailed summary.

Generally I agree with the high level goal, as for the details of provided macros, I'll need more time to give you some feedback. Probably after devconf (after this weekend). Feel free to locate me on devconf and discuss this in person if you'd like, I'll be on the Fedora/Python/PyLadies multi-booth.

I'm a bit confused here... Why are we doing this instead of using the sysusers stuff that was added for us?

Also, this looks really similar to the rpm-helper stuff that Mageia and OpenMandriva have. Perhaps there's an opportunity to learn from that and try to avoid the pitfalls of those implementations (and maybe have them collaborate on this too?)

cc: @akien

I'm a bit confused here... Why are we doing this instead of using the sysusers stuff that was added for us?

I'll ping @harald to answer this part because I forget the details, but I think it turned out that the macros had some flaws in them. This implementation will use sysusers under the hood, but it's a more generic framework.

Also, this looks really similar to the rpm-helper stuff that Mageia and OpenMandriva have. Perhaps there's an opportunity to learn from that and try to avoid the pitfalls of those implementations (and maybe have them collaborate on this too?)
cc: @akien

Could you point at some resources on rpm-helper?

Could you point at some resources on rpm-helper?

There's a Git repo: http://gitweb.mageia.org/software/rpm/rpm-helper/about/

Its usage is kind of detailed here: https://wiki.mageia.org/en/Packagers_RPM_tutorial#More_macros

@akien may know more, as he's been a Mageia packager longer than I have...

@sgallagh There's also another tool like this (though with slightly different focus and scope) from Solus called usysconf that allowed them to mostly ban package scripts entirely.

Login to comment on this ticket.

Metadata