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

[Colin Guthrie]

'Twas brillig, and Tobias Geerinckx-Rice at 10/07/14 15:53 did gyre and
gimble:
> 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.

Well, this is a reasonable assumption overall I guess, especially
considering the "usual" logic of overriding supported elsewhere in
similar tools.

It would only break things in future if basic.conf changed to have more
essential users. I would suggest that we should put some of these
"standard", but legacy, users into a legacy.conf instead which should
lessen the risk of future updates should you override it on your system
(and assuming this patch is accepted!)

>> 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 is :)

But sadly that's the way it's been done for a while, but now that there
is a mechanism to decouple this from pre scripts, we'll be good.

(there is a small issue of ownership of certain files according to rpm -
e.g. if the package wants to ship files that are user or group owned by
users the package itself creates - but I suspect most of these cases
will refer to files in /etc or /var both of which should be
bootstrapable and thus have files fixed up by tmpfiles so it's likely
not a huge issue practically speaking).

> Replacing this kind of distribution-level system user "management" --
> if any -- with something remotely scalable still smells like a good
> idea. 

Yup, totally agree. I really like the sysusers.d stuff generally and
look forward to cleaning up a lot of packages to get rid of these old
%pre bits

> 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*.

Well, the issue there is one of file ownership. Typically these users
are created on installation but never purged on uninstall simply because
files may have been stored using those users. e.g.
/var/spool/clamav/virusmails/ might all be owned by clamav. If the user
was purged when clamav was removed, all that data might sit there owned
by the uid/gid (no longer attached to a named account).

If then some other package is installed, and it creates a user account
it *might* pick up the uid/gid vacated by clamav and thus suddenly
become the owner of that data. This could obviously then be a vector for
a data leak.

That's the reasoning. There may be a better solution (such as scanning
all files to find those owned by the uid/gid and deleting them on
package removal), but this is the simplest - i.e. leave it to the admin!


> 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?

Don't get me wrong, I really like sysusers.d/ It's just the slight
chicken and egg thing that seems slightly odd! I'm not totally against
this patch, but I do worry that it enables some weird corner cases when
bootstrapping /etc/ from empty - but those are probably not big enough
concerns to justify not accepting the patch!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/