On Fri, 11 Mar 2022 at 12:08:27 +0100, Simon Richter wrote:
> On 3/10/22 8:59 PM, Michael Biebl wrote:
> > have you considered a more declarative approach as provided by
> > systemd-sysusers (8)?
>
> We currently don't have a good mechanism for leaving configuration behind on
> purge, which we've historically done with user accounts to avoid reuse of
> UIDs that may own resources, so we'd still have to create the declarations
> from a postinst.
Why would that be desirable? systemd-sysusers isn't a NSS plugin that
magics users into existence without them existing (unlike libnss-systemd,
which is part of the implementation of DynamicUser). Instead,
systemd-sysusers reads its declarative source files and uses them
to populate the state of the system user database (in practice that
usually means /etc/passwd). If the user already exists in the system user
database, then it won't go away just because the source file was removed.
Using flatpak as my example of a "modern" package that creates a system
user (which is named _flatpak as per Policy §9.2.1), what we currently
do is:
install flatpak
postinst invokes adduser
adduser adds _flatpak to /etc/passwd
remove flatpak
nothing special happens
_flatpak continues to exist in /etc/passwd
(some packages use usermod -L here, but I'm not clear on what
benefit that provides, so flatpak currently doesn't)
purge flatpak
nothing special happens
_flatpak continues to exist in /etc/passwd
and the equivalent if we were relying on sysusers would be this:
install flatpak
/usr/lib/sysusers.d/flatpak.conf is created
postinst or trigger invokes systemd-sysusers
systemd-sysusers adds _flatpak to /etc/passwd
remove flatpak
/usr/lib/sysusers.d/flatpak.conf is removed
_flatpak continues to exist in /etc/passwd
purge flatpak
nothing special happens
_flatpak continues to exist in /etc/passwd
In fact flatpak already installs /usr/lib/sysusers.d/flatpak.conf - partly
because its upstream developer wants to support distros that already
rely on sysusers to manage system uids, partly as a small step towards
stateless systems being able to boot with an empty /etc, and partly as
a way to document in a declarative way that flatpak "owns" the _flatpak
account. It doesn't currently make use of that file in the postinst,
because Policy recommends using adduser (imperatively), but it could if
we wanted to.
On a system where flatpak has ever been installed (even if it was
subsequently removed), the only situation in which the _flatpak user would
cease to exist would be if it was explicitly removed from /etc/passwd,
perhaps as part of a "factory reset" procedure. If that happens,
I think the correct behaviour would be to recreate it (if flatpak is
still installed and still needs it) or leave it absent (otherwise) -
which is what systemd-sysusers would "naturally" do on the next reboot,
if left to do its job.
smcv
