picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

man: mention that DynamicUser= should not be mixed with ReadWriteDirectory= or AF_UNIX dir fd passing

This commit is contained in:
Lennart Poettering 2019-03-12 15:57:25 +01:00 committed by Zbigniew Jędrzejewski-Szmek
parent 5763971014
commit c648d4d4c8
1 changed files with 42 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
man/systemd.exec.xml
View File

@ -217,40 +217,49 @@
<varlistentry>
<term><varname>DynamicUser=</varname></term>
<listitem><para>Takes a boolean parameter. If set, a UNIX user and group pair is allocated dynamically when the
unit is started, and released as soon as it is stopped. The user and group will not be added to
<filename>/etc/passwd</filename> or <filename>/etc/group</filename>, but are managed transiently during
runtime. The <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
glibc NSS module provides integration of these dynamic users/groups into the system's user and group
<listitem><para>Takes a boolean parameter. If set, a UNIX user and group pair is allocated
dynamically when the unit is started, and released as soon as it is stopped. The user and group will
not be added to <filename>/etc/passwd</filename> or <filename>/etc/group</filename>, but are managed
transiently during runtime. The
<citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> glibc
NSS module provides integration of these dynamic users/groups into the system's user and group
databases. The user and group name to use may be configured via <varname>User=</varname> and
<varname>Group=</varname> (see above). If these options are not used and dynamic user/group allocation is
enabled for a unit, the name of the dynamic user/group is implicitly derived from the unit name. If the unit
name without the type suffix qualifies as valid user name it is used directly, otherwise a name incorporating a
hash of it is used. If a statically allocated user or group of the configured name already exists, it is used
and no dynamic user/group is allocated. Note that if <varname>User=</varname> is specified and the static group
with the name exists, then it is required that the static user with the name already exists. Similarly, if
<varname>Group=</varname> is specified and the static user with the name exists, then it is required that the
static group with the name already exists. Dynamic users/groups are allocated from the UID/GID range
61184…65519. It is recommended to avoid this range for regular system or login users. At any point in time
each UID/GID from this range is only assigned to zero or one dynamically allocated users/groups in
use. However, UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running
as part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these
users/groups around, as a different unit might get the same UID/GID assigned later on, and thus gain access to
these files or directories. If <varname>DynamicUser=</varname> is enabled, <varname>RemoveIPC=</varname>,
<varname>PrivateTmp=</varname> are implied. This ensures that the lifetime of IPC objects and temporary files
created by the executed processes is bound to the runtime of the service, and hence the lifetime of the dynamic
user/group. Since <filename>/tmp</filename> and <filename>/var/tmp</filename> are usually the only
world-writable directories on a system this ensures that a unit making use of dynamic user/group allocation
cannot leave files around after unit termination. Moreover <varname>ProtectSystem=strict</varname> and
<varname>ProtectHome=read-only</varname> are implied, thus prohibiting the service to write to arbitrary file
system locations. In order to allow the service to write to certain directories, they have to be whitelisted
using <varname>ReadWritePaths=</varname>, but care must be taken so that UID/GID recycling doesn't create
security issues involving files created by the service. Use <varname>RuntimeDirectory=</varname> (see below) in
order to assign a writable runtime directory to a service, owned by the dynamic user/group and removed
automatically when the unit is terminated. Use <varname>StateDirectory=</varname>,
<varname>CacheDirectory=</varname> and <varname>LogsDirectory=</varname> in order to assign a set of writable
directories for specific purposes to the service in a way that they are protected from vulnerabilities due to
UID reuse (see below). Defaults to off.</para></listitem>
<varname>Group=</varname> (see above). If these options are not used and dynamic user/group
allocation is enabled for a unit, the name of the dynamic user/group is implicitly derived from the
unit name. If the unit name without the type suffix qualifies as valid user name it is used directly,
otherwise a name incorporating a hash of it is used. If a statically allocated user or group of the
configured name already exists, it is used and no dynamic user/group is allocated. Note that if
<varname>User=</varname> is specified and the static group with the name exists, then it is required
that the static user with the name already exists. Similarly, if <varname>Group=</varname> is
specified and the static user with the name exists, then it is required that the static group with
the name already exists. Dynamic users/groups are allocated from the UID/GID range 61184…65519. It is
recommended to avoid this range for regular system or login users. At any point in time each UID/GID
from this range is only assigned to zero or one dynamically allocated users/groups in use. However,
UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as
part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by
these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus
gain access to these files or directories. If <varname>DynamicUser=</varname> is enabled,
<varname>RemoveIPC=</varname>, <varname>PrivateTmp=</varname> are implied. This ensures that the
lifetime of IPC objects and temporary files created by the executed processes is bound to the runtime
of the service, and hence the lifetime of the dynamic user/group. Since <filename>/tmp</filename> and
<filename>/var/tmp</filename> are usually the only world-writable directories on a system this
ensures that a unit making use of dynamic user/group allocation cannot leave files around after unit
termination. Moreover <varname>ProtectSystem=strict</varname> and
<varname>ProtectHome=read-only</varname> are implied, thus prohibiting the service to write to
arbitrary file system locations. In order to allow the service to write to certain directories, they
have to be whitelisted using <varname>ReadWritePaths=</varname>, but care must be taken so that
UID/GID recycling doesn't create security issues involving files created by the service. Use
<varname>RuntimeDirectory=</varname> (see below) in order to assign a writable runtime directory to a
service, owned by the dynamic user/group and removed automatically when the unit is terminated. Use
<varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname> and
<varname>LogsDirectory=</varname> in order to assign a set of writable directories for specific
purposes to the service in a way that they are protected from vulnerabilities due to UID reuse (see
below). If this option is enabled, care should be taken that the unit's processes do not get access
to directories outside of these explicitly configured and managed ones. Specifically, do not use
<varname>BindPaths=</varname> and be careful with <constant>AF_UNIX</constant> file descriptor
passing for directory file descriptors, as this would permit processes to create files or directories
owned by the dynamic user/group that are not subject to the life-cycle and access guarantees of the
service. Defaults to off.</para></listitem>
</varlistentry>
<varlistentry>