Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 02, 2020 at 10:29:26AM -0500, Neal Gompa wrote:
> On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
> >
> > https://fedoraproject.org/wiki/Changes/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: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
> > * Email: zbyszek at in waw pl
> >
> > == Detailed Description ==
> >
> > Many packages define their own user. Right now, those users are
> > created in %pre by calling getent, useradd, and groupadd
> > ([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation
> > guidelines]). This will be changed to define users in the
> > [https://www.freedesktop.org/software/systemd/man/sysusers.d.html
> > 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.
> >
> > In this proposal, systemd-sysusers will not be used to create 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
> > ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
> > guidelines]), but does not use separate rpm packages. I think using a
> > %pre macro is good enough.
> >
> > == Benefit to Fedora ==
> >
> > System users are declared by packages using a uniform syntax.
> >
> > The scriptlet part is standardized. 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.
> >
> 
> While this *is* incrementally better than before, there *is* a reason
> for using separate RPM packages as openSUSE does. There are many cases
> where a user+group is actually shared across multiple packages, and
> having the user+group definition broken out into a subpackage means
> that it's easy for multiple packages to depend on it without having to
> depend on the program package.

For those cases, a separate package can be split out, similarly to any
other case of resources shared between packages. I didn't want to make
the split mandatory because I assumed that sharing a user between
completely independent packages is something of a fringe case...
(The case when there's a single "main" package and a bunch of add-on
packages which use the same user doesn't count here, because in that
case it's easy enough to define the user in the "main" package.)
Apart from web servers, what are the use cases?

> For example, in openSUSE, there is a wwwrun user paired with the www
> group (there's also a wwwrun group, but it doesn't matter quite that
> much). This user+group combination is used by *all* webservers.

> It also has a static ID, so that it's consistent across installs.

Fedora pretty much gave up on static UIDs a while back. We use "dynamic"
allocation pretty much all the time. Nevertheless, I don't think that
static vs. dynamic matters for this, since all the discussed mechanisms
(current useradd+groupadd, proposed mechanism, or opensuse mechanism
with separate packages) would give the same id allocations.

> Moreover, the *definition* of the user+group is centralized,
> making it easier to audit and adjust over time.

I don't grok this sentence. In my proposal the definition of a user is
a single sysusers.d file. It is owned by some specific package, and in
this sense the definition is centralized (unique). IIUC, opensuse has
a similar setup, with the main difference being that the file is shunted
to a separate package, i.e. there is just as much "centralization".

> Also importantly,
> there's a dependency generator that generates user() and group()
> Provides for this, so that packages can just declare they need that
> user+group combo to exist first before the package can be installed.

This can be added too.

> I would like us to be able to do that in Fedora too, as it would
> drastically simplify some of the odd issues we have with managing
> shared users and groups across multiple packages (web servers,
> language runtime environments, git services, etc.).

I was not aware of those problems. Can you give me some pointers to
those issues?

> For us, since we don't have the SUSE patches that make PreReq do
> things, the way we'd declare this with upstream RPM features would be:
> 
> Requires: user(wwwrun)
> OrderWithRequires: user(wwwrun)
> 
> That way, it's always installed before the package in question is.

Sure, I don't see why not.

Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux