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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 10, 2014 at 02:41:14PM +0100, Colin Guthrie wrote:
> 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.
This probably wouldn't be useful for the case when /etc is bootstrapped,
like you say below.

> What if you create a tmpfiles snippet to create a
> /etc/sysusers.d/foo.conf file, does that mean we have to run tmpfiles
> before sysusers?
I think that's a bit of an artificial problem. Like with everything
else, the outcome depends on the ordering.  What would happen if
tmpfiles.d were to create a .service file in /etc/systemd/system?
Anyway, in this specific case, I believe sysusers should run before
tmpfiles, so it is possible to use tmpfiles to create files owned
by users created by sysusers.
 
> 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.
Currently, even if you delete a user like this, there's no mechanism
to prevent recreation on the next update of this or another unrelated
package. So in some sense it is even worse, because with normal rpm
scripts you are safe until this specific package is upgraded.

But anyway, I find it very nice that the configuration loading mechanism
is consistent between tools, and this inability to override sysusers
is annoying.

Zbyszek