capability sets as documented in
<citerefentry><refentrytitle>cap_from_text</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
Note that these capability sets are
- usually influenced by the capabilities
+ usually influenced (and filtered) by the capabilities
attached to the executed file. Due to
that
<varname>CapabilityBoundingSet=</varname>
<term><varname>ReadOnlyDirectories=</varname></term>
<term><varname>InaccessibleDirectories=</varname></term>
- <listitem><para>Sets up a new
- file system namespace for executed
+ <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
processes inside the namespace. Note
that restricting access with these
options does not extend to submounts
- of a directory. You must list
- submounts separately in these settings
- to ensure the same limited
- access. These options may be specified
+ of a directory that are created later
+ on. These options may be specified
more than once in which case all
directories 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
+ option, the specific list is reset,
+ and all prior assignments have no
effect.</para>
<para>Paths in
<varname>ReadOnlyDirectories=</varname>
accessible).</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>ProtectSystem=</varname></term>
+
+ <listitem><para>Takes a boolean
+ argument or
+ <literal>full</literal>. If true,
+ mounts the <filename>/usr</filename>
+ directory read-only for processes
+ invoked by this unit. If set to
+ <literal>full</literal> the
+ <filename>/etc</filename> is mounted
+ read-only, too. This setting ensures
+ that any modification of the vendor
+ supplied operating system (and
+ optionally its configuration) is
+ prohibited for the service. It is
+ recommended to enable this setting for
+ all long-running services, unless they
+ are involved with system updates or
+ need to modify the operating system in
+ other ways. Note however, that
+ processes retaining the CAP_SYS_ADMIN
+ capability can undo the effect of this
+ setting. This setting is hence
+ particularly useful for daemons which
+ have this capability removed, for
+ example with
+ <varname>CapabilityBoundingSet=</varname>. Defaults
+ to off.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>ProtectHome=</varname></term>
+
+ <listitem><para>Takes a boolean
+ argument or
+ <literal>read-only</literal>. If true,
+ the directories
+ <filename>/home</filename> and
+ <filename>/run/user</filename> are
+ made inaccessible and empty for
+ processes invoked by this unit. If set
+ to <literal>read-only</literal> the
+ two directores are made read-only
+ instead. It is recommended to enable
+ this setting for all long-running
+ services (in particular network-facing
+ ones), to ensure they cannot get access
+ to private user data, unless the
+ services actually require access to
+ the user's private data. Note however,
+ that processes retaining the
+ CAP_SYS_ADMIN capability can undo the
+ effect of this setting. This setting
+ is hence particularly useful for
+ daemons which have this capability
+ removed, for example with
+ <varname>CapabilityBoundingSet=</varname>. Defaults
+ to off.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>MountFlags=</varname></term>
namespace related options
(<varname>PrivateTmp=</varname>,
<varname>PrivateDevices=</varname>,
+ <varname>ReadOnlySystem=</varname>,
+ <varname>ProtectedHome=</varname>,
<varname>ReadOnlyDirectories=</varname>,
<varname>InaccessibleDirectories=</varname>
and
<literal>/</literal>, i.e. must refer
to simple directories to create or
remove. This is particularly useful
- for unpriviliges daemons that cannot
+ for unprivileged daemons that cannot
create runtime directories in
<filename>/run</filename> due to lack
of privileges, and to make sure the
~ianmdlvl / elogind.git / blobdiff