Discussion:
systemd-sysusers
Add Reply
Johannes Ernst
2018-02-04 23:31:07 UTC
Reply
Permalink
Raw Message
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?

Thanks,



Johannes.
Michael Chapman
2018-02-05 05:56:50 UTC
Reply
Permalink
Raw Message
Post by Johannes Ernst
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.

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.
Reindl Harald
2018-02-05 09:26:09 UTC
Reply
Permalink
Raw Message
Post by Michael Chapman
Post by Johannes Ernst
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.
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.
i hope you meant systemd-tmpfiles-setup.service is ordered before
systemd-sysusers.service and you simply talked about "Before=" which in
fact means ordered after
Mantas Mikulėnas
2018-02-05 09:41:28 UTC
Reply
Permalink
Raw Message
Post by Reindl Harald
Post by Michael Chapman
Post by Johannes Ernst
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.
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.
i hope you meant systemd-tmpfiles-setup.service is ordered before
systemd-sysusers.service and you simply talked about "Before=" which in
fact means ordered after
"Before=" means before. "After=" means after. If Unit A has "After=B", then
A is ordered after B.

$ systemctl cat systemd-tmpfiles-setup.service
# /usr/lib/systemd/system/systemd-tmpfiles-setup.service


[Unit]
Description=Create Volatile Files and Directories
Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)
DefaultDependencies=no
Conflicts=shutdown.target
*After=local-fs.target systemd-sysusers.service*
--
Mantas Mikulėnas
Michael Chapman
2018-02-05 09:47:35 UTC
Reply
Permalink
Raw Message
Post by Reindl Harald
Post by Michael Chapman
Post by Johannes Ernst
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.
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.
i hope you meant systemd-tmpfiles-setup.service is ordered before
systemd-sysusers.service and you simply talked about "Before=" which in fact
means ordered after
Sorry, I cannot work out what you are saying.

Take a look at the unit files as shipped in systemd.
systemd-tmpfiles-setup.service is ordered After=systemd-sysusers.service
(which is, as far as I can tell, equivalent to what I said before). It
needs to be that way around for a tmpfiles.d fragment to be able to
reference a user created by systemd-sysusers.
Reindl Harald
2018-02-05 09:50:19 UTC
Reply
Permalink
Raw Message
Post by Michael Chapman
Post by Reindl Harald
 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.
 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.
i hope you meant systemd-tmpfiles-setup.service is ordered before
systemd-sysusers.service and you simply talked about "Before=" which
in fact means ordered after
Sorry, I cannot work out what you are saying.
Take a look at the unit files as shipped in systemd.
systemd-tmpfiles-setup.service is ordered After=systemd-sysusers.service
(which is, as far as I can tell, equivalent to what I said before). It
needs to be that way around for a tmpfiles.d fragment to be able to
reference a user created by systemd-sysusers.
buffer overflow - coffee missing - sorry
Johannes Ernst
2018-02-05 18:21:17 UTC
Reply
Permalink
Raw Message
Post by Johannes Ernst
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:

systemd-sysusers
[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
chown $(id -u foo):$(id -g foo) /var/lib/foo

I’d rather prefer a flag (if not the default) in the .conf file saying “create directory if it does not exist”. Perhaps worth adding?

But thanks for confirming that I didn’t miss anything, and I indeed need to jump through this hoop.

Cheers,



Johannes.
Zbigniew Jędrzejewski-Szmek
2018-02-05 18:31:22 UTC
Reply
Permalink
Raw Message
Post by Johannes Ernst
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.
systemd-sysusers
[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
chown $(id -u foo):$(id -g foo) /var/lib/foo
# /usr/lib/tmpfiles.d/foo.conf
d /var/lib/foo 0755 foo foo -

(BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo ...).

Zbyszek
Johannes Ernst
2018-02-05 18:35:45 UTC
Reply
Permalink
Raw Message
<snip>
Post by Zbigniew Jędrzejewski-Szmek
Post by Johannes Ernst
systemd-sysusers
[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
chown $(id -u foo):$(id -g foo) /var/lib/foo
# /usr/lib/tmpfiles.d/foo.conf
d /var/lib/foo 0755 foo foo -
(BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo …).
Good point :-)

If so, the wording in man systemd-tmpfiles.d is still rather discouraging to people like me to do it this way because it very clearly talks about “temporary” files.

Thanks,



Johannes.
Reindl Harald
2018-02-05 18:39:51 UTC
Reply
Permalink
Raw Message
Post by Johannes Ernst
<snip>
Post by Zbigniew Jędrzejewski-Szmek
Post by Johannes Ernst
systemd-sysusers
[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
chown $(id -u foo):$(id -g foo) /var/lib/foo
# /usr/lib/tmpfiles.d/foo.conf
d /var/lib/foo 0755 foo foo -
(BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo …).
Good point :-)
If so, the wording in man systemd-tmpfiles.d is still rather discouraging to people like me to do it this way because it very clearly talks about “temporary” files
because the stuff in /tmp and especially /run *is* temporary based on
the nature of tmpfs
Lennart Poettering
2018-02-05 19:56:10 UTC
Reply
Permalink
Raw Message
Post by Michael Chapman
Post by Johannes Ernst
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 :-)
Post by Michael Chapman
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
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
Loading...