<refsect1>
<title>Mandatory Access Control</title>
- <variablelist>
+ <variablelist class='unit-directives'>
<varlistentry>
<term><varname>SELinuxContext=</varname></term>
<refsect1>
<title>Process Properties</title>
- <variablelist>
+ <variablelist class='unit-directives'>
<varlistentry>
<term><varname>LimitCPU=</varname></term>
<refsect1>
<title>Scheduling</title>
- <variablelist>
+ <variablelist class='unit-directives'>
<varlistentry>
<term><varname>Nice=</varname></term>
(such as <varname>ProtectSystem=</varname>) are not available, as the underlying kernel functionality is only
accessible to privileged processes.</para>
- <variablelist>
+ <variablelist class='unit-directives'>
<varlistentry>
<term><varname>ProtectSystem=</varname></term>
security.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>ProtectHostname=</varname></term>
+
+ <listitem><para>Takes a boolean argument. When set, sets up a new UTS namespace for the executed
+ processes. In addition, changing hostname or domainname is prevented. Defaults to off.</para>
+
+ <para>Note that the implementation of this setting might be impossible (for example if UTS namespaces are not
+ available), and the unit should be written in a way that does not solely rely on this setting for
+ security.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>ProtectKernelTunables=</varname></term>
<constant>SHM_EXEC</constant> set. Note that this option is incompatible with programs and libraries that
generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code
"trampoline" feature of various C compilers. This option improves service security, as it makes harder for
- software exploits to change running code dynamically. Note that this feature is fully available on x86-64, and
- partially on x86. Specifically, the <function>shmat()</function> protection is not available on x86. Note that
- on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for
- services, so that they cannot be used to circumvent the restrictions of this option. Specifically, it is
- recommended to combine this option with <varname>SystemCallArchitectures=native</varname> or similar. If
- running in user mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability
- (e.g. setting <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is implied.</para></listitem>
+ software exploits to change running code dynamically. However, the protection can be circumvented, if
+ the service can write to a filesystem, which is not mounted with <constant>noexec</constant> (such as
+ <filename>/dev/shm</filename>), or it can use <function>memfd_create()</function>. This can be
+ prevented by making such file systems inaccessible to the service
+ (e.g. <varname>InaccessiblePaths=/dev/shm</varname>) and installing further system call filters
+ (<varname>SystemCallFilter=~memfd_create</varname>). Note that this feature is fully available on
+ x86-64, and partially on x86. Specifically, the <function>shmat()</function> protection is not
+ available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is
+ recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the
+ restrictions of this option. Specifically, it is recommended to combine this option with
+ <varname>SystemCallArchitectures=native</varname> or similar. If running in user mode, or in system
+ mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting
+ <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is implied.</para></listitem>
</varlistentry>
<varlistentry>
<refsect1>
<title>System Call Filtering</title>
- <variablelist>
+ <variablelist class='unit-directives'>
<varlistentry>
<term><varname>SystemCallFilter=</varname></term>
<refsect1>
<title>Environment</title>
- <variablelist>
+ <variablelist class='unit-directives'>
<varlistentry>
<term><varname>Environment=</varname></term>
<refsect1>
<title>Logging and Standard Input/Output</title>
- <variablelist>
+ <variablelist class='unit-directives'>
<varlistentry>
<term><varname>StandardInput=</varname></term>
<refsect1>
<title>System V Compatibility</title>
- <variablelist>
+ <variablelist class='unit-directives'>
<varlistentry>
<term><varname>UtmpIdentifier=</varname></term>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><varname>$PIDFILE</varname></term>
+
+ <listitem><para>The path to the configured PID file, in case the process is forked off on behalf of a
+ service that uses the <varname>PIDFile=</varname> setting, see
+ <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details. Service code may use this environment variable to automatically generate a PID file at
+ the location configured in the unit file. This field is set to an absolute path in the file
+ system.</para></listitem>
+ </varlistentry>
+
</variablelist>
<para>For system services, when <varname>PAMName=</varname> is enabled and <command>pam_systemd</command> is part
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
projects / thirdparty / systemd.git / blobdiff