[systemd-devel] [PATCH] sysusers: allow overrides in /etc and /run

Tobias Geerinckx-Rice tobias.geerinckx.rice at gmail.com
Thu Jul 10 07:53:24 PDT 2014


On 10 July 2014 13:41, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>
> 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 10/07/14 13:51 did
> gyre and gimble:
> > An administrator might want to block a certain sysusers config file from
> > being executed, e.g. to block the creation of a certain user.
> I guess this is probably OK, but isn't it a bit counter intuitive? I
> mean one of the reasons for sysuser is due to /etc/ being bootstrapped.
> In this case I'd have thought that looking in /etc/ is a bit weird.

Starting one's laptop in 2014 and seeing a new "tape" user added is
also a bit weird :-) Although I'm running -git at the moment, not a
distribution package, so maybe that's not what's supposed to happen.

My first reaction was to create my own /etc/sysuser.d/basic.conf
without it. Of course, that didn't work. Oh well. It wouldn't have
been an ideal solution anyway, probably breaking future upgrades if
the upstream basic.conf were to change.

> But then I do accept that when sysusers is used for non-bootstrapping
> (i.e. just instead of the %pre useradd in RPM scripts and the like) it
> might be something an administrator would want to override. That said,
> AFAIK, there is no way to override this current with rpm scripts, so I
> wonder if this is really something to bother supporting ongoing.

<non-contributor tangent alert>

I don't use RPM, but having your system's user policy consist of
running useradd in a pre-installation script seems... sub-optimal. It
also forces de facto namespace standardisation, without any of the
benefits.

Replacing this kind of distribution-level system user "management" --
if any -- with something remotely scalable still smells like a good
idea. So does separating package-managed users/groups from
administrator-managed ones: my /etc/groups currently contains
"openvpn", "clamav" and "kvm", despite my having purged those packages
ages ago. Why? I'm not convinced that users or admins, no matter how
grey their beards, should be expected to manage such details *by
default*.

Having packages contain or depend on a sysusers.d/<username>.conf
containing the relevant fields seems like a nice solution, with /etc
then allowing full customisation. Or am I missing something obvious?

Regards, Tobias


More information about the systemd-devel mailing list