[systemd-devel] systemd-sysusers

Lennart Poettering lennart at poettering.net
Mon Feb 5 19:56:10 UTC 2018


On Mo, 05.02.18 10:21, Johannes Ernst (johannes.ernst at gmail.com) wrote:

> >> It appears systemd-sysusers does not create home directories. On
> >> the other hand, it picks (largely unpredictable) UIDs from a
> >> range.
> >> 
> >> So I have to run systemd-sysusers, and after that, find the UID
> >> of the user and chown the home directory? Or is there the
> >> equivalent of the “useradd -m” flag somewhere that I’m just not
> >> seeing?
> > 
> > systemd-sysusers is, as the name suggests, really for _system_
> > users, and often those kinds of users don't have ordinary home
> > directories -- that is, ones the user can actually write to.
> 
> I agree with the “often” but not more :-)
> 
> > However, systemd-sysusers.service is ordered before
> > systemd-tmpfiles-setup.service at boot, so if you need to create a
> > system user's home directory and ensure its ownership is correct,
> > you could use a corresponding tmpfiles.d fragment to do so.
> 
> Hmm … tmpfiles.d, according to its man page, is for “the creation,
> cleaning and removal of volatile and temporary files and directories
> which usually reside in directories such as /run or /tmp.”. That
> doesn’t really seem to cover home directories that contain actual
> data.
> 
> Here’s my use case: Take a package for a daemon foo. The package
> contains a foo.service, and when foo runs, it is supposed to run in
> its own little place /var/lib/foo where it stores its data
> files. Because not everybody runs foo, it doesn’t make sense to pick
> a “fixed” UID like for more common daemons. Allocating a UID from a
> pool, like sysusers does, seems perfect. But how does the package
> ship /var/lib/foo? It can’t ship with owner foo because we don’t
> know what its UID is going to be. So the package, as part of its
> install script, needs to do something like:

My recommendation: simply use StateDirectory=foo in the service's unit
file (along with User=foo) to make things simpler and more robust. In
that case the directory is created automatically when the service is
started first, and chown()ed to the selected user. Note that this
works even if your service wants to drop privs on its own, because in
that case you can prefix its ExecStart= command line with "!", which
disables systemd's UID dropping code for that line. That way you can
safely declare a user in a service so that StateDirectory= has the
right ownership without this also implying systemd drops privs for
you.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list