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. Defaults to off.</para></listitem>
+ 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>
</varlistentry>
<varlistentry>
<para>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 <literal>(sd-pam)</literal> and
- is an immediate child process of the unit's main process.</para></listitem>
+ is an immediate child process of the unit's main process.</para>
+
+ <para>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
+ <varname>PAMName=</varname> 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 <varname>NotifyAccess=</varname><option>all</option>, 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 <varname>PAMName=</varname> in
+ combination with <varname>NotifyAccess=</varname><option>all</option>.</para>
+ </listitem>
</varlistentry>
<varlistentry>
</row>
</thead>
<tbody>
+ <row>
+ <entry>@aio</entry>
+ <entry>Asynchronous I/O (<citerefentry project='man-pages'><refentrytitle>io_setup</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>io_submit</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+ </row>
<row>
<entry>@basic-io</entry>
<entry>System calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing (<citerefentry project='man-pages'><refentrytitle>read</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>write</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
</row>
+ <row>
+ <entry>@chown</entry>
+ <entry>Changing file ownership (<citerefentry project='man-pages'><refentrytitle>chown</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>fchownat</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+ </row>
<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>
<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>@credentials</entry>
- <entry>System calls for querying process credentials (<citerefentry project='man-pages'><refentrytitle>getuid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>capget</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>
<entry>@swap</entry>
<entry>System calls for enabling/disabling swap devices (<citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>swapoff</refentrytitle><manvolnum>2</manvolnum></citerefentry>)</entry>
</row>
+ <row>
+ <entry>@sync</entry>
+ <entry>Synchronizing files and memory to disk: (<citerefentry project='man-pages'><refentrytitle>fsync</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>msync</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+ </row>
<row>
<entry>@timer</entry>
<entry>System calls for scheduling operations by time (<citerefentry project='man-pages'><refentrytitle>alarm</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>timer_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
<varname>NoNewPrivileges=yes</varname> is implied.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>KeyringMode=</varname></term>
+
+ <listitem><para>Controls how the kernel session keyring is set up for the service (see <citerefentry
+ project='man-pages'><refentrytitle>session-keyring</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+ details on the session keyring). Takes one of <option>inherit</option>, <option>private</option>,
+ <option>shared</option>. If set to <option>inherit</option> no special keyring setup is done, and the kernel's
+ default behaviour is applied. If <option>private</option> is used a new session keyring is allocated when a
+ service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for
+ system services, as this ensures that multiple services running under the same system user ID (in particular
+ the root user) do not share their key material among each other. If <option>shared</option> is used a new
+ session keyring is allocated as for <option>private</option>, but the user keyring of the user configured with
+ <varname>User=</varname> is linked into it, so that keys assigned to the user may be requested by the unit's
+ processes. In this modes multiple units running processes under the same user ID may share key material. Unless
+ <option>inherit</option> is selected the unique invocation ID for the unit (see below) is added as a protected
+ key by the name <literal>invocation_id</literal> to the newly created session keyring. Defaults to
+ <option>private</option> for the system service manager and to <option>inherit</option> for the user service
+ manager.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>RuntimeDirectory=</varname></term>
+ <term><varname>StateDirectory=</varname></term>
+ <term><varname>CacheDirectory=</varname></term>
+ <term><varname>LogsDirectory=</varname></term>
+ <term><varname>ConfigurationDirectory=</varname></term>
- <listitem><para>Takes a whitespace-separated list of directory names. The specified directory names must be
- relative, and may not include <literal>.</literal> or <literal>..</literal>. If set, one or more directories
- including their parents by the specified names will be created below <filename>/run</filename> (for system
- services) or below <varname>$XDG_RUNTIME_DIR</varname> (for user services) when the unit is started. The
- lowest subdirectories are removed when the unit is stopped. It is possible to preserve the directories if
- <varname>RuntimeDirectoryPreserve=</varname> is configured to <option>restart</option> or <option>yes</option>.
- The lowest subdirectories will have the access mode specified in <varname>RuntimeDirectoryMode=</varname>,
- and be owned by the user and group specified in <varname>User=</varname> and <varname>Group=</varname>.
- This implies <varname>ReadWritePaths=</varname>, that is, the directories specified
- in this option are accessible with the access mode specified in <varname>RuntimeDirectoryMode=</varname>
- even if <varname>ProtectSystem=</varname> is set to <option>strict</option>.
- Use this to manage one or more runtime directories of the unit and bind their
- lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create
+ <listitem><para>These options take a whitespace-separated list of directory names. The specified directory
+ names must be relative, and may not include <literal>.</literal> or <literal>..</literal>. If set, one or more
+ directories by the specified names will be created (including their parents) below <filename>/run</filename>
+ (or <varname>$XDG_RUNTIME_DIR</varname> for user services), <filename>/var/lib</filename> (or
+ <varname>$XDG_CONFIG_HOME</varname> for user services), <filename>/var/cache</filename> (or
+ <varname>$XDG_CACHE_HOME</varname> for user services), <filename>/var/log</filename> (or
+ <varname>$XDG_CONFIG_HOME</varname><filename>/log</filename> for user services), or <filename>/etc</filename>
+ (or <varname>$XDG_CONFIG_HOME</varname> for user services), respectively, when the unit is started.</para>
+
+ <para>In case of <varname>RuntimeDirectory=</varname> the lowest subdirectories are removed when the unit is
+ stopped. It is possible to preserve the specified directories in this case if
+ <varname>RuntimeDirectoryPreserve=</varname> is configured to <option>restart</option> or <option>yes</option>
+ (see below). The directories specified with <varname>StateDirectory=</varname>,
+ <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>,
+ <varname>ConfigurationDirectory=</varname> are not removed when the unit is stopped.</para>
+
+ <para>Except in case of <varname>ConfigurationDirectory=</varname>, the innermost specified directories will be
+ owned by the user and group specified in <varname>User=</varname> and <varname>Group=</varname>. If the
+ specified directories already exist and their owning user or group do not match the configured ones, all files
+ and directories below the specified directories as well as the directories themselves will have their file
+ ownership recursively changed to match what is configured. As an optimization, if the specified directories are
+ already owned by the right user and group, files and directories below of them are left as-is, even if they do
+ not match what is requested. The innermost specified directories will have their access mode adjusted to the
+ what is specified in <varname>RuntimeDirectoryMode=</varname>, <varname>StateDirectoryMode=</varname>,
+ <varname>CacheDirectoryMode=</varname>, <varname>LogsDirectoryMode=</varname> and
+ <varname>ConfigurationDirectoryMode=</varname>.</para>
+
+ <para>Except in case of <varname>ConfigurationDirectory=</varname>, these options imply
+ <varname>ReadWritePaths=</varname> for the specified paths. When combined with
+ <varname>RootDirectory=</varname> or <varname>RootImage=</varname> these paths always reside on the host and
+ are mounted from there into the unit's file system namespace. If <varname>DynamicUser=</varname> is used in
+ conjunction with <varname>RuntimeDirectory=</varname>, <varname>StateDirectory=</varname>,
+ <varname>CacheDirectory=</varname> and <varname>LogsDirectory=</varname>, the behaviour of these options is
+ slightly altered: the directories are created below <filename>/run/private</filename>,
+ <filename>/var/lib/private</filename>, <filename>/var/cache/private</filename> and
+ <filename>/var/log/private</filename>, respectively, which are host directories made inaccessible to
+ unprivileged users, which ensures that access to these directories cannot be gained through dynamic user ID
+ recycling. Symbolic links are created to hide this difference in behaviour. Both from perspective of the host
+ and from inside the unit, the relevant directories hence always appear directly below
+ <filename>/run</filename>, <filename>/var/lib</filename>, <filename>/var/cache</filename> and
+ <filename>/var/log</filename>.</para>
+
+ <para>Use <varname>RuntimeDirectory=</varname> to manage one or more runtime directories for the unit and bind
+ their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create
runtime directories in <filename>/run</filename> due to lack of privileges, and to make sure the runtime
- directory is cleaned up automatically after use. For runtime directories that require more complex or
- different configuration or lifetime guarantees, please consider using
+ directory is cleaned up automatically after use. For runtime directories that require more complex or different
+ configuration or lifetime guarantees, please consider using
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
<para>Example: if a system service unit has the following,
except <filename>/run/foo</filename> are owned by the user and group specified in <varname>User=</varname> and
<varname>Group=</varname>, and removed when the service is stopped.
</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><varname>StateDirectory=</varname></term>
- <term><varname>CacheDirectory=</varname></term>
- <term><varname>LogsDirectory=</varname></term>
- <term><varname>ConfigurationDirectory=</varname></term>
- <listitem><para>Takes a whitespace-separated list of directory names. If set, as similar to
- <varname>RuntimeDirectory=</varname>, one or more directories including their parents by the specified names
- will be created below <filename>/var/lib</filename>, <filename>/var/cache</filename>, <filename>/var/log</filename>,
- or <filename>/etc</filename>, respectively, when the unit is started.
- Unlike <varname>RuntimeDirectory=</varname>, the directories are not removed when the unit is stopped.
- The lowest subdirectories will be owned by the user and group specified in <varname>User=</varname>
- and <varname>Group=</varname>. The options imply <varname>ReadWritePaths=</varname>.
- </para></listitem>
</varlistentry>
<varlistentry>
projects / thirdparty / systemd.git / blobdiff