required to access <filename>/tmp</filename> and
<filename>/var/tmp</filename>.</para>
- <para>Units whose output standard output or error output is
- connected to any other sink but <option>null</option>,
- <option>tty</option> and <option>socket</option> automatically
- acquire dependencies of type <varname>After=</varname> on
- <filename>journald.socket</filename>.</para>
+ <para>Units whose standard output or error output is connected to <option>journal</option>, <option>syslog</option>
+ or <option>kmsg</option> (or their combinations with console output, see below) automatically acquire dependencies
+ of type <varname>After=</varname> on <filename>systemd-journald.socket</filename>.</para>
</refsect1>
<refsect1>
<varlistentry>
<term><varname>WorkingDirectory=</varname></term>
- <listitem><para>Takes an absolute directory path, or the
+ <listitem><para>Takes a directory path relative to the service's root
+ directory specified by <varname>RootDirectory=</varname>, or the
special value <literal>~</literal>. Sets the working directory
for executed processes. If set to <literal>~</literal>, the
home directory of the user specified in
and the respective user's home directory if run as user. If
the setting is prefixed with the <literal>-</literal>
character, a missing working directory is not considered
- fatal. Note that setting this parameter might result in
+ fatal. If <varname>RootDirectory=</varname> is not set, then
+ <varname>WorkingDirectory=</varname> is relative to the root of
+ the system running the service manager.
+ Note that setting this parameter might result in
additional dependencies to be added to the unit (see
above).</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>RootDirectory=</varname></term>
- <listitem><para>Takes an absolute directory path. Sets the
+ <listitem><para>Takes a directory path relative to the host's root directory
+ (i.e. the root of the system running the service manager). Sets the
root directory for executed processes, with the <citerefentry
project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
system call. If this is used, it must be ensured that the
<term><varname>User=</varname></term>
<term><varname>Group=</varname></term>
- <listitem><para>Sets the Unix user or group that the processes
- are executed as, respectively. Takes a single user or group
- name or ID as argument. If no group is set, the default group
- of the user is chosen.</para></listitem>
+ <listitem><para>Set the UNIX user or group that the processes are executed as, respectively. Takes a single
+ user or group name, or numeric ID as argument. 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 <literal>!</literal>.</para></listitem>
+ </varlistentry>
+
+ <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
+ 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. 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>PrivateTmp=</varname> is
+ implied. This ensures that the lifetime of 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. 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. Defaults to
+ off.</para></listitem>
</varlistentry>
<varlistentry>
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.</para></listitem>
+ user. This does not affect commands prefixed with <literal>!</literal>.</para></listitem>
</varlistentry>
<varlistentry>
similar to the same option of
<varname>StandardInput=</varname>.</para>
+ <para>If the standard output (or error output, see below) of a unit is connected to the journal, syslog or the
+ kernel log buffer, the unit will implicitly gain a dependency of type <varname>After=</varname> on
+ <filename>systemd-journald.socket</filename> (also see the automatic dependencies section above).</para>
+
<para>This setting defaults to the value set with
<option>DefaultStandardOutput=</option> in
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<term><varname>LimitNICE=</varname></term>
<term><varname>LimitRTPRIO=</varname></term>
<term><varname>LimitRTTIME=</varname></term>
- <listitem><para>These settings set both soft and hard limits
- of various resources for executed processes. See
- <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
- for details. The resource limit is possible to specify in two formats,
- <option>value</option> to set soft and hard limits to the same value,
- or <option>soft:hard</option> to set both limits individually (e.g. LimitAS=4G:16G).
- Use the string <varname>infinity</varname> to
- configure no limit on a specific resource. The multiplicative
- suffixes K (=1024), M (=1024*1024) and so on for G, T, P and E
- may be used for resource limits measured in bytes
- (e.g. LimitAS=16G). For the limits referring to time values,
- the usual time units ms, s, min, h and so on may be used (see
- <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- for details). Note that if no time unit is specified for
- <varname>LimitCPU=</varname> the default unit of seconds is
- implied, while for <varname>LimitRTTIME=</varname> the default
- unit of microseconds is implied. Also, note that the effective
- granularity of the limits might influence their
- enforcement. For example, time limits specified for
- <varname>LimitCPU=</varname> will be rounded up implicitly to
- multiples of 1s.</para>
+ <listitem><para>Set soft and hard limits on various resources for executed processes. See
+ <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> for details on
+ the resource limit concept. Resource limits may be specified in two formats: either as single value to set a
+ specific soft and hard limit to the same value, or as colon-separated pair <option>soft:hard</option> to set
+ both limits individually (e.g. <literal>LimitAS=4G:16G</literal>). Use the string <varname>infinity</varname>
+ to configure no limit on a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base
+ 1024) may be used for resource limits measured in bytes (e.g. LimitAS=16G). For the limits referring to time
+ values, the usual time units ms, s, min, h and so on may be used (see
+ <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+ details). Note that if no time unit is specified for <varname>LimitCPU=</varname> the default unit of seconds
+ is implied, while for <varname>LimitRTTIME=</varname> the default unit of microseconds is implied. Also, note
+ that the effective granularity of the limits might influence their enforcement. For example, time limits
+ specified for <varname>LimitCPU=</varname> will be rounded up implicitly to multiples of 1s. For
+ <varname>LimitNICE=</varname> the value may be specified in two syntaxes: if prefixed with <literal>+</literal>
+ or <literal>-</literal>, the value is understood as regular Linux nice value in the range -20..19. If not
+ prefixed like this the value is understood as raw resource limit parameter in the range 0..40 (with 0 being
+ equivalent to 1).</para>
<para>Note that most process resource limits configured with
these options are per-process, and processes may fork in order
<varlistentry>
<term><varname>CapabilityBoundingSet=</varname></term>
+ <listitem><para>Controls which capabilities to include in the capability bounding set for the executed
+ process. See <citerefentry
+ project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+ details. Takes a whitespace-separated list of capability names as read by <citerefentry
+ project='mankier'><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+ e.g. <constant>CAP_SYS_ADMIN</constant>, <constant>CAP_DAC_OVERRIDE</constant>,
+ <constant>CAP_SYS_PTRACE</constant>. Capabilities listed will be included in the bounding set, all others are
+ removed. If the list of capabilities is prefixed with <literal>~</literal>, all but the listed capabilities
+ will be included, the effect of the assignment inverted. Note that this option also affects the respective
+ capabilities in the effective, permitted and inheritable capability sets. If this option is not used, the
+ capability bounding set is not modified on process execution, hence no limits on the capabilities of the
+ process are enforced. This option may appear more than once, in which case the bounding sets are merged. If the
+ empty string is assigned to this option, the bounding set is reset to the empty capability set, and all prior
+ settings have no effect. If set to <literal>~</literal> (without any further argument), the bounding set is
+ reset to the full set of available capabilities, also undoing any previous settings. This does not affect
+ commands prefixed with <literal>!</literal>.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>AmbientCapabilities=</varname></term>
+
<listitem><para>Controls which capabilities to include in the
- capability bounding set for the executed process. See
- <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- for details. Takes a whitespace-separated list of capability
- names as read by
+ ambient capability set for the executed process. Takes a
+ whitespace-separated list of capability names as read by
<citerefentry project='mankier'><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
e.g. <constant>CAP_SYS_ADMIN</constant>,
<constant>CAP_DAC_OVERRIDE</constant>,
- <constant>CAP_SYS_PTRACE</constant>. Capabilities listed will
- be included in the bounding set, all others are removed. If
- the list of capabilities is prefixed with
- <literal>~</literal>, all but the listed capabilities will be
- included, the effect of the assignment inverted. Note that
- this option also affects the respective capabilities in the
- effective, permitted and inheritable capability sets, on top
- of what <varname>Capabilities=</varname> does. If this option
- is not used, the capability bounding set is not modified on
- process execution, hence no limits on the capabilities of the
- process are enforced. This option may appear more than once, in
- which case the bounding sets are merged. If the empty string
- is assigned to this option, the bounding set is reset to the
- empty capability set, and all prior settings have no effect.
- If set to <literal>~</literal> (without any further argument),
- the bounding set is reset to the full set of available
- capabilities, also undoing any previous
- settings.</para></listitem>
+ <constant>CAP_SYS_PTRACE</constant>. This option may appear more than
+ once in which case the ambient capability sets are merged.
+ If the list of capabilities is prefixed with <literal>~</literal>, all
+ but the listed capabilities will be included, the effect of the
+ assignment inverted. If the empty string is
+ assigned to this option, the ambient capability set is reset to
+ the empty capability set, and all prior settings have no effect.
+ If set to <literal>~</literal> (without any further argument), the
+ ambient capability set is reset to the full set of available
+ capabilities, also undoing any previous settings. Note that adding
+ capabilities to ambient capability set adds them to the process's
+ inherited capability set.
+ </para><para>
+ Ambient capability sets are useful if you want to execute a process
+ as a non-privileged user but still want to give it some capabilities.
+ Note that in this case option <constant>keep-caps</constant> is
+ automatically added to <varname>SecureBits=</varname> to retain the
+ capabilities over the user change. <varname>AmbientCapabilities=</varname> does not affect
+ commands prefixed with <literal>!</literal>.</para></listitem>
</varlistentry>
<varlistentry>
<option>noroot-locked</option>.
This option may appear more than once, in which case the secure
bits are ORed. If the empty string is assigned to this option,
- the bits are reset to 0. See
- <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ the bits are reset to 0. This does not affect commands prefixed with <literal>!</literal>.
+ See <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for details.</para></listitem>
</varlistentry>
<varlistentry>
- <term><varname>Capabilities=</varname></term>
- <listitem><para>Controls the
- <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- set for the executed process. Take a capability string
- describing the effective, permitted and inherited capability
- sets as documented in
- <citerefentry project='mankier'><refentrytitle>cap_from_text</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
- Note that these capability sets are usually influenced (and
- filtered) by the capabilities attached to the executed file.
- Due to that <varname>CapabilityBoundingSet=</varname> is
- probably a much more useful setting.</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><varname>ReadWriteDirectories=</varname></term>
- <term><varname>ReadOnlyDirectories=</varname></term>
- <term><varname>InaccessibleDirectories=</varname></term>
+ <term><varname>ReadWritePaths=</varname></term>
+ <term><varname>ReadOnlyPaths=</varname></term>
+ <term><varname>InaccessiblePaths=</varname></term>
<listitem><para>Sets up a new file system namespace for
executed processes. These options may be used to limit access
a process might have to the main file system hierarchy. Each
- setting takes a space-separated list of absolute directory
- paths. Directories listed in
- <varname>ReadWriteDirectories=</varname> are accessible from
+ setting takes a space-separated list of paths relative to
+ the host's root directory (i.e. the system running the service manager).
+ Note that if entries contain symlinks, they are resolved from the host's root directory as well.
+ Entries (files or directories) listed in
+ <varname>ReadWritePaths=</varname> are accessible from
within the namespace with the same access rights as from
- outside. Directories listed in
- <varname>ReadOnlyDirectories=</varname> are accessible for
+ outside. Entries listed in
+ <varname>ReadOnlyPaths=</varname> are accessible for
reading only, writing will be refused even if the usual file
- access controls would permit this. Directories listed in
- <varname>InaccessibleDirectories=</varname> will be made
- inaccessible for processes inside the namespace. Note that
- restricting access with these options does not extend to
- submounts of a directory that are created later on. These
+ access controls would permit this. Entries listed in
+ <varname>InaccessiblePaths=</varname> will be made
+ inaccessible for processes inside the namespace, and may not
+ countain any other mountpoints, including those specified by
+ <varname>ReadWritePaths=</varname> or
+ <varname>ReadOnlyPaths=</varname>.
+ Note that restricting access with these options does not extend
+ to submounts of a directory that are created later on.
+ Non-directory paths can be specified as well. These
options may be specified more than once, in which case all
- directories listed will have limited access from within the
+ paths listed will have limited access from within the
namespace. If the empty string is assigned to this option, the
specific list is reset, and all prior assignments have no
effect.</para>
<para>Paths in
- <varname>ReadOnlyDirectories=</varname>
+ <varname>ReadOnlyPaths=</varname>
and
- <varname>InaccessibleDirectories=</varname>
+ <varname>InaccessiblePaths=</varname>
may be prefixed with
<literal>-</literal>, in which case
they will be ignored when they do not
(propagation in the opposite direction continues to work).
This means that this setting may not be used for services
which shall be able to install mount points in the main mount
- namespace.</para></listitem>
+ namespace. The /dev namespace will be mounted read-only and 'noexec'.
+ The latter may break old programs which try to set up executable
+ memory by using <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+ of <filename>/dev/zero</filename> instead of using <constant>MAP_ANON</constant>.</para></listitem>
</varlistentry>
<varlistentry>
<varname>PrivateDevices=</varname>,
<varname>ProtectSystem=</varname>,
<varname>ProtectHome=</varname>,
- <varname>ReadOnlyDirectories=</varname>,
- <varname>InaccessibleDirectories=</varname> and
- <varname>ReadWriteDirectories=</varname>) require that mount
+ <varname>ReadOnlyPaths=</varname>,
+ <varname>InaccessiblePaths=</varname> and
+ <varname>ReadWritePaths=</varname>) require that mount
and unmount propagation from the unit's file system namespace
is disabled, and hence downgrade <option>shared</option> to
<option>slave</option>. </para></listitem>
domain transition. However, the policy still needs to
authorize the transition. This directive is ignored if SELinux
is disabled. If prefixed by <literal>-</literal>, all errors
- will be ignored. See
- <citerefentry project='die-net'><refentrytitle>setexeccon</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ will be ignored. This does not affect commands prefixed with <literal>!</literal>.
+ See <citerefentry project='die-net'><refentrytitle>setexeccon</refentrytitle><manvolnum>3</manvolnum></citerefentry>
for details.</para></listitem>
</varlistentry>
Profiles must already be loaded in the kernel, or the unit
will fail. This result in a non operation if AppArmor is not
enabled. If prefixed by <literal>-</literal>, all errors will
- be ignored. </para></listitem>
+ be ignored. This does not affect commands prefixed with <literal>!</literal>.</para></listitem>
</varlistentry>
<varlistentry>
<para>The value may be prefixed by <literal>-</literal>, in
which case all errors will be ignored. An empty value may be
- specified to unset previous assignments.</para>
+ specified to unset previous assignments. This does not affect
+ commands prefixed with <literal>!</literal>.</para>
</listitem>
</varlistentry>
first character of the list is <literal>~</literal>, the
effect is inverted: only the listed system calls will result
in immediate process termination (blacklisting). If running in
- user mode and this option is used,
+ user mode, or in system mode, but without the
+ <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting
+ <varname>User=nobody</varname>),
<varname>NoNewPrivileges=yes</varname> is implied. This
feature makes use of the Secure Computing Mode 2 interfaces of
the kernel ('seccomp filtering') and is useful for enforcing a
listed explicitly. This option may be specified more than once,
in which case the filter masks are merged. If the empty string
is assigned, the filter is reset, all prior assignments will
- have no effect.</para>
+ have no effect. This does not affect commands prefixed with <literal>!</literal>.</para>
<para>If you specify both types of this option (i.e.
whitelisting and blacklisting), the first encountered will
<function>read</function> and <function>write</function>, and
right after it add a blacklisting of
<function>write</function>, then <function>write</function>
- will be removed from the set.) </para></listitem>
+ will be removed from the set.)</para>
+
+ <para>As the number of possible system
+ calls is large, predefined sets of system calls are provided.
+ A set starts with <literal>@</literal> character, followed by
+ name of the set.
+
+ <table>
+ <title>Currently predefined system call sets</title>
+
+ <tgroup cols='2'>
+ <colspec colname='set' />
+ <colspec colname='description' />
+ <thead>
+ <row>
+ <entry>Set</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>@clock</entry>
+ <entry>System calls for changing the system clock (<citerefentry project='man-pages'><refentrytitle>adjtimex</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>settimeofday</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+ </row>
+ <row>
+ <entry>@cpu-emulation</entry>
+ <entry>System calls for CPU emulation functionality (<citerefentry project='man-pages'><refentrytitle>vm86</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+ </row>
+ <row>
+ <entry>@debug</entry>
+ <entry>Debugging, performance monitoring and tracing functionality (<citerefentry project='man-pages'><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>perf_event_open</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+ </row>
+ <row>
+ <entry>@io-event</entry>
+ <entry>Event loop system calls (<citerefentry project='man-pages'><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>eventfd</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+ </row>
+ <row>
+ <entry>@ipc</entry>
+ <entry>SysV IPC, POSIX Message Queues or other IPC (<citerefentry project='man-pages'><refentrytitle>mq_overview</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>svipc</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+ </row>
+ <row>
+ <entry>@keyring</entry>
+ <entry>Kernel keyring access (<citerefentry project='man-pages'><refentrytitle>keyctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+ </row>
+ <row>
+ <entry>@module</entry>
+ <entry>Kernel module control (<citerefentry project='man-pages'><refentrytitle>init_module</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>delete_module</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+ </row>
+ <row>
+ <entry>@mount</entry>
+ <entry>File system mounting and unmounting (<citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+ </row>
+ <row>
+ <entry>@network-io</entry>
+ <entry>Socket I/O (including local AF_UNIX): <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry></entry>
+ </row>
+ <row>
+ <entry>@obsolete</entry>
+ <entry>Unusual, obsolete or unimplemented (<citerefentry project='man-pages'><refentrytitle>create_module</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>gtty</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
+ </row>
+ <row>
+ <entry>@privileged</entry>
+ <entry>All system calls which need super-user capabilities (<citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+ </row>
+ <row>
+ <entry>@process</entry>
+ <entry>Process control, execution, namespaces (<citerefentry project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>, …</entry>
+ </row>
+ <row>
+ <entry>@raw-io</entry>
+ <entry>Raw I/O port access (<citerefentry project='man-pages'><refentrytitle>ioperm</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>iopl</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <function>pciconfig_read()</function>, …</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ Note, that as new system calls are added to the kernel, additional system calls might be added to the groups
+ above, so the contents of the sets may change between systemd versions.</para></listitem>
</varlistentry>
<varlistentry>
systems. The special <constant>native</constant> identifier
implicitly maps to the native architecture of the system (or
more strictly: to the architecture the system manager is
- compiled for). If running in user mode and this option is
- used, <varname>NoNewPrivileges=yes</varname> is implied. Note
+ compiled for). If running in user mode, or in system mode,
+ but without the <constant>CAP_SYS_ADMIN</constant>
+ capability (e.g. setting <varname>User=nobody</varname>),
+ <varname>NoNewPrivileges=yes</varname> is implied. Note
that setting this option to a non-empty list implies that
<constant>native</constant> is included too. By default, this
option is set to the empty list, i.e. no architecture system
<function>socketpair()</function> (which creates connected
AF_UNIX sockets only) are unaffected. Note that this option
has no effect on 32-bit x86 and is ignored (but works
- correctly on x86-64). If running in user mode and this option
- is used, <varname>NoNewPrivileges=yes</varname> is implied. By
+ correctly on x86-64). If running in user mode, or in system
+ mode, but without the <constant>CAP_SYS_ADMIN</constant>
+ capability (e.g. setting <varname>User=nobody</varname>),
+ <varname>NoNewPrivileges=yes</varname> is implied. By
default, no restriction applies, all address families are
accessible to processes. If assigned the empty string, any
previous list changes are undone.</para>
family should be included in the configured whitelist as it is
frequently used for local communication, including for
<citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>2</manvolnum></citerefentry>
- logging.</para></listitem>
+ logging. This does not affect commands prefixed with <literal>!</literal>.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>Personality=</varname></term>
- <listitem><para>Controls which kernel architecture
- <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
- shall report, when invoked by unit processes. Takes one of
- <constant>x86</constant> and <constant>x86-64</constant>. This
- is useful when running 32-bit services on a 64-bit host
- system. If not specified, the personality is left unmodified
- and thus reflects the personality of the host system's
- kernel.</para></listitem>
+ <listitem><para>Controls which kernel architecture <citerefentry
+ project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry> shall report,
+ when invoked by unit processes. Takes one of the architecture identifiers <constant>x86</constant>,
+ <constant>x86-64</constant>, <constant>ppc</constant>, <constant>ppc-le</constant>, <constant>ppc64</constant>,
+ <constant>ppc64-le</constant>, <constant>s390</constant> or <constant>s390x</constant>. Which personality
+ architectures are supported depends on the system architecture. Usually the 64bit versions of the various
+ system architectures support their immediate 32bit personality architecture counterpart, but no others. For
+ example, <constant>x86-64</constant> systems support the <constant>x86-64</constant> and
+ <constant>x86</constant> personalities but no others. The personality feature is useful when running 32-bit
+ services on a 64-bit host system. If not specified, the personality is left unmodified and thus reflects the
+ personality of the host system's kernel.</para></listitem>
</varlistentry>
<varlistentry>
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>MemoryDenyWriteExecute=</varname></term>
+
+ <listitem><para>Takes a boolean argument. If set, attempts to create memory mappings that are writable and
+ executable at the same time, or to change existing memory mappings to become executable are prohibited.
+ Specifically, a system call filter is added that rejects
+ <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+ system calls with both <constant>PROT_EXEC</constant> and <constant>PROT_WRITE</constant> set
+ and <citerefentry><refentrytitle>mprotect</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+ system calls with <constant>PROT_EXEC</constant> set. Note that this option is incompatible with programs
+ that generate program code dynamically at runtime, such as JIT execution engines, or programs compiled making
+ use of the code "trampoline" feature of various C compilers. This option improves service security, as it makes
+ harder for software exploits to change running code dynamically.
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>RestrictRealtime=</varname></term>
+
+ <listitem><para>Takes a boolean argument. If set, any attempts to enable realtime scheduling in a process of
+ the unit are refused. This restricts access to realtime task scheduling policies such as
+ <constant>SCHED_FIFO</constant>, <constant>SCHED_RR</constant> or <constant>SCHED_DEADLINE</constant>. See
+ <citerefentry><refentrytitle>sched</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details about
+ these scheduling policies. Realtime scheduling policies may be used to monopolize CPU time for longer periods
+ of time, and may hence be used to lock up or otherwise trigger Denial-of-Service situations on the system. It
+ is hence recommended to restrict access to realtime scheduling to the few programs that actually require
+ them. Defaults to off.</para></listitem>
+ </varlistentry>
+
</variablelist>
</refsect1>
<citerefentry project='man-pages'><refentrytitle>termcap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><varname>$JOURNAL_STREAM</varname></term>
+
+ <listitem><para>If the standard output or standard error output of the executed processes are connected to the
+ journal (for example, by setting <varname>StandardError=journal</varname>) <varname>$JOURNAL_STREAM</varname>
+ contains the device and inode numbers of the connection file descriptor, formatted in decimal, separated by a
+ colon (<literal>:</literal>). This permits invoked processes to safely detect whether their standard output or
+ standard error output are connected to the journal. The device and inode numbers of the file descriptors should
+ be compared with the values set in the environment variable to determine whether the process output is still
+ connected to the journal. Note that it is generally not sufficient to only check whether
+ <varname>$JOURNAL_STREAM</varname> is set at all as services might invoke external processes replacing their
+ standard output or standard error output, without unsetting the environment variable.</para>
+
+ <para>This environment variable is primarily useful to allow services to optionally upgrade their used log
+ protocol to the native journal protocol (using
+ <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry> and other
+ functions) if their standard output or standard error output is connected to the journal anyway, thus enabling
+ delivery of structured metadata along with logged messages.</para></listitem>
+ </varlistentry>
</variablelist>
<para>Additional variables may be configured by the following
projects / thirdparty / systemd.git / blobdiff