конфигурация среды выполнения (Execution environment configuration)
USER/GROUP IDENTITY
These options are only available for system services and are not
supported for services running in per-user instances of the
service manager.
User=, Group=
Set the UNIX user or group that the processes are executed
as, respectively. Takes a single user or group name, or a
numeric ID as argument. For system services (services run by
the system service manager, i.e. managed by PID 1) and for
user services of the root user (services managed by root's
instance of systemd --user), the default is "root", but User=
may be used to specify a different user. For user services of
any other user, switching user identity is not permitted,
hence the only valid setting is the same user the user's
service manager is running as. If no group is set, the
default group of the user is used. This setting does not
affect commands whose command line is prefixed with "+".
Note that this enforces only weak restrictions on the
user/group name syntax, but will generate warnings in many
cases where user/group names do not adhere to the following
rules: the specified name should consist only of the
characters a-z, A-Z, 0-9, "_" and "-", except for the first
character which must be one of a-z, A-Z and "_" (i.e. digits
and "-" are not permitted as first character). The user/group
name must have at least one character, and at most 31. These
restrictions are made in order to avoid ambiguities and to
ensure user/group names and unit files remain portable among
Linux systems. For further details on the names accepted and
the names warned about see User/Group Name Syntax
When used in conjunction with DynamicUser= the user/group
name specified is dynamically allocated at the time the
service is started, and released at the time the service is
stopped — unless it is already allocated statically (see
below). If DynamicUser= is not used the specified user and
group must have been created statically in the user database
no later than the moment the service is started, for example
using the sysusers.d(5) facility, which is applied at boot or
package install time. If the user does not exist by then
program invocation will fail.
If the User= setting is used the supplementary group list is
initialized from the specified user's default group list, as
defined in the system's user and group database. Additional
groups may be configured through the SupplementaryGroups=
setting (see below).
DynamicUser=
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 /etc/passwd or /etc/group, but are managed
transiently during runtime. The nss-systemd(8) 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 User= and Group= (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 User= 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 Group= 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 DynamicUser= is enabled, RemoveIPC=
and PrivateTmp= are implied (and cannot be turned off). 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 /tmp/ and /var/tmp/ 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. Furthermore
NoNewPrivileges= and RestrictSUIDSGID= are implicitly enabled
(and cannot be disabled), to ensure that processes invoked
cannot take benefit or create SUID/SGID files or directories.
Moreover ProtectSystem=strict and ProtectHome=read-only 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 allow-listed using
ReadWritePaths=, but care must be taken so that UID/GID
recycling doesn't create security issues involving files
created by the service. Use RuntimeDirectory= (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 StateDirectory=,
CacheDirectory= and LogsDirectory= 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 BindPaths= and be
careful with AF_UNIX 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 lifecycle and access guarantees of the
service. Defaults to off.
SupplementaryGroups=
Sets the supplementary Unix groups the processes are executed
as. This takes a space-separated list of group names or IDs.
This option may be specified more than once, in which case
all listed groups are set as supplementary groups. When the
empty string is assigned, the list of supplementary groups is
reset, and all assignments prior to this one will have no
effect. In any way, this option does not override, but
extends the list of supplementary groups configured in the
system group database for the user. This does not affect
commands prefixed with "+".
PAMName=
Sets the PAM service name to set up a session as. If set, the
executed process will be registered as a PAM session under
the specified service name. This is only useful in
conjunction with the User= setting, and is otherwise ignored.
If not set, no PAM session will be opened for the executed
processes. See pam(8) for details.
Note that for each unit making use of this option a PAM
session handler process will be maintained as part of the
unit and stays around as long as the unit is active, to
ensure that appropriate actions can be taken when the unit
and hence the PAM session terminates. This process is named
"(sd-pam)" and is an immediate child process of the unit's
main process.
Note that when this option is used for a unit it is very
likely (depending on PAM configuration) that the main unit
process will be migrated to its own session scope unit when
it is activated. This process will hence be associated with
two units: the unit it was originally started from (and for
which PAMName= was configured), and the session scope unit.
Any child processes of that process will however be
associated with the session scope unit only. This has
implications when used in combination with NotifyAccess=all,
as these child processes will not be able to affect changes
in the original unit through notification messages. These
messages will be considered belonging to the session scope
unit and not the original unit. It is hence not recommended
to use PAMName= in combination with NotifyAccess=all.
