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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)