+ are implicitly whitelisted and do not
+ need to be 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>
+
+ <para>If you specify both types of
+ this option (i.e. whitelisting and
+ blacklisting), the first encountered
+ will take precedence and will dictate
+ the default action (termination or
+ approval of a system call). Then the
+ next occurrences of this option will
+ add or delete the listed system calls
+ from the set of the filtered system
+ calls, depending of its type and the
+ default action. (For example, if you have started
+ with a whitelisting of
+ <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>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>SystemCallErrorNumber=</varname></term>
+
+ <listitem><para>Takes an
+ <literal>errno</literal> error number
+ name to return when the system call
+ filter configured with
+ <varname>SystemCallFilter=</varname>
+ is triggered, instead of terminating
+ the process immediately. Takes an
+ error name such as
+ <constant>EPERM</constant>,
+ <constant>EACCES</constant> or
+ <constant>EUCLEAN</constant>. When this
+ setting is not used, or when the empty
+ string is assigned, the process will be
+ terminated immediately when the filter
+ is triggered.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>SystemCallArchitectures=</varname></term>
+
+ <listitem><para>Takes a space
+ separated list of architecture
+ identifiers to include in the system
+ call filter. The known architecture
+ identifiers are
+ <constant>x86</constant>,
+ <constant>x86-64</constant>,
+ <constant>x32</constant>,
+ <constant>arm</constant> as well as
+ the special identifier
+ <constant>native</constant>. Only
+ system calls of the specified
+ architectures will be permitted to
+ processes of this unit. This is an
+ effective way to disable compatibility
+ with non-native architectures for
+ processes, for example to prohibit
+ execution of 32-bit x86 binaries on
+ 64-bit x86-64 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 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 call filtering is
+ applied.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>RestrictAddressFamilies=</varname></term>
+
+ <listitem><para>Restricts the set of
+ socket address families accessible to
+ the processes of this unit. Takes a
+ space-separated list of address family
+ names to whitelist, such as
+ <constant>AF_UNIX</constant>,
+ <constant>AF_INET</constant> or
+ <constant>AF_INET6</constant>. When
+ prefixed with <constant>~</constant>
+ the listed address families will be
+ applied as blacklist, otherwise as
+ whitelist. Note that this restricts
+ access to the
+ <citerefentry><refentrytitle>socket</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+ system call only. Sockets passed into
+ the process by other means (for
+ example, by using socket activation
+ with socket units, see
+ <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+ are unaffected. Also, sockets created
+ with <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 default, no
+ restriction applies, all address
+ families are accessible to
+ processes. If assigned the empty
+ string, any previous list changes are
+ undone.</para>
+
+ <para>Use this option to limit
+ exposure of processes to remote
+ systems, in particular via exotic
+ network protocols. Note that in most
+ cases, the local
+ <constant>AF_UNIX</constant> address
+ 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>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>Personality=</varname></term>
+
+ <listitem><para>Controls which
+ kernel architecture
+ <citerefentry><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>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>RuntimeDirectory=</varname></term>
+ <term><varname>RuntimeDirectoryMode=</varname></term>
+
+ <listitem><para>Takes a list of
+ directory names. If set, one or more
+ directories 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, and removed when the unit is
+ stopped. The directories will have the
+ access mode specified in
+ <varname>RuntimeDirectoryMode=</varname>,
+ and will be owned by the user and
+ group specified in
+ <varname>User=</varname> and
+ <varname>Group=</varname>. Use this to
+ manage one or more runtime directories
+ of the unit and bind their lifetime to
+ the daemon runtime. The specified
+ directory names must be relative, and
+ may not include a
+ <literal>/</literal>, i.e. must refer
+ to simple directories to create or
+ remove. 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
+ <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+ </varlistentry>
+
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <title>Environment variables in spawned processes</title>
+
+ <para>Processes started by the system are executed in
+ a clean environment in which select variables
+ listed below are set. System processes started by systemd
+ do not inherit variables from PID 1, but processes
+ started by user systemd instances inherit all
+ environment variables from the user systemd instance.
+ </para>
+
+ <variablelist class='environment-variables'>
+ <varlistentry>
+ <term><varname>$PATH</varname></term>
+
+ <listitem><para>Colon-separated list
+ of directiories to use when launching
+ executables. Systemd uses a fixed
+ value of
+ <filename>/usr/local/sbin</filename>:<filename>/usr/local/bin</filename>:<filename>/usr/sbin</filename>:<filename>/usr/bin</filename>:<filename>/sbin</filename>:<filename>/bin</filename>.
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>$LANG</varname></term>
+
+ <listitem><para>Locale. Can be set in
+ <citerefentry><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ or on the kernel command line (see
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ and
+ <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>).
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>$USER</varname></term>
+ <term><varname>$LOGNAME</varname></term>
+ <term><varname>$HOME</varname></term>
+ <term><varname>$SHELL</varname></term>
+
+ <listitem><para>User name (twice), home
+ directory, and the login shell.
+ The variables are set for the units that
+ have <varname>User=</varname> set,
+ which includes user
+ <command>systemd</command> instances.
+ See
+ <citerefentry><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>$XDG_RUNTIME_DIR</varname></term>
+
+ <listitem><para>The directory for volatile
+ state. Set for the user <command>systemd</command>
+ instance, and also in user sessions.
+ See
+ <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+ </para></listitem>