man: describe interaction with ProtectHome=/InaccessiblePaths= in BindMount=

https://github.com/systemd/systemd/issues/7153#issuecomment-485252308

Apparently this is still confusing for people.

Longer-term, I think we should just make BindMount= automatically "upgrade"
(or "downgrade", depending on how you look at this), any InaccessiblePath=
mountpoints to "tmpfs". I don't see much point in forcing users to remember
this interaction. But let's at least document the status quo, we can always
update the docs if the code changes.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2019-04-23 10:28:38 +02:00 committed by Lennart Poettering
parent 99b43caf26
commit db8d154dc4

View file

@ -180,6 +180,13 @@
is used. In this case the source path refers to a path on the host file system, while the destination path is used. In this case the source path refers to a path on the host file system, while the destination path
refers to a path below the root directory of the unit.</para> refers to a path below the root directory of the unit.</para>
<para>Note that the destination directory must exist or systemd must be able to create it. Thus, it
is not possible to use those options for mount points nested underneath paths specified in
<varname>InaccessiblePaths=</varname>, or under <filename>/home/</filename> and other protected
directories if <varname>ProtectHome=yes</varname> is
specified. <varname>TemporaryFileSystem=</varname> with <literal>:ro</literal> or
<varname>ProtectHome=tmpfs</varname> should be used instead.</para>
<xi:include href="system-only.xml" xpointer="singular"/></listitem> <xi:include href="system-only.xml" xpointer="singular"/></listitem>
</varlistentry> </varlistentry>
@ -822,23 +829,25 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
<term><varname>ProtectHome=</varname></term> <term><varname>ProtectHome=</varname></term>
<listitem><para>Takes a boolean argument or the special values <literal>read-only</literal> or <listitem><para>Takes a boolean argument or the special values <literal>read-only</literal> or
<literal>tmpfs</literal>. If true, the directories <filename>/home</filename>, <filename>/root</filename> and <literal>tmpfs</literal>. If true, the directories <filename>/home</filename>,
<filename>/run/user</filename> are made inaccessible and empty for processes invoked by this unit. If set to <filename>/root</filename>, and <filename>/run/user</filename> are made inaccessible and empty for
<literal>read-only</literal>, the three directories are made read-only instead. If set to <literal>tmpfs</literal>, processes invoked by this unit. If set to <literal>read-only</literal>, the three directories are
temporary file systems are mounted on the three directories in read-only mode. The value <literal>tmpfs</literal> made read-only instead. If set to <literal>tmpfs</literal>, temporary file systems are mounted on the
is useful to hide home directories not relevant to the processes invoked by the unit, while necessary directories three directories in read-only mode. The value <literal>tmpfs</literal> is useful to hide home
are still visible by combining with <varname>BindPaths=</varname> or <varname>BindReadOnlyPaths=</varname>.</para> directories not relevant to the processes invoked by the unit, while still allowing necessary
directories to be made visible when listed in <varname>BindPaths=</varname> or
<varname>BindReadOnlyPaths=</varname>.</para>
<para>Setting this to <literal>yes</literal> is mostly equivalent to set the three directories in <para>Setting this to <literal>yes</literal> is mostly equivalent to set the three directories in
<varname>InaccessiblePaths=</varname>. Similarly, <literal>read-only</literal> is mostly equivalent to <varname>InaccessiblePaths=</varname>. Similarly, <literal>read-only</literal> is mostly equivalent to
<varname>ReadOnlyPaths=</varname>, and <literal>tmpfs</literal> is mostly equivalent to <varname>ReadOnlyPaths=</varname>, and <literal>tmpfs</literal> is mostly equivalent to
<varname>TemporaryFileSystem=</varname>.</para> <varname>TemporaryFileSystem=</varname> with <literal>:ro</literal>.</para>
<para> It is recommended to enable this setting for all long-running services (in particular network-facing <para>It is recommended to enable this setting for all long-running services (in particular
ones), to ensure they cannot get access to private user data, unless the services actually require access to network-facing ones), to ensure they cannot get access to private user data, unless the services
the user's private data. This setting is implied if <varname>DynamicUser=</varname> is set. This setting cannot actually require access to the user's private data. This setting is implied if
ensure protection in all cases. In general it has the same limitations as <varname>ReadOnlyPaths=</varname>, <varname>DynamicUser=</varname> is set. This setting cannot ensure protection in all cases. In
see below.</para> general it has the same limitations as <varname>ReadOnlyPaths=</varname>, see below.</para>
<xi:include href="system-only.xml" xpointer="singular"/></listitem> <xi:include href="system-only.xml" xpointer="singular"/></listitem>
</varlistentry> </varlistentry>
@ -1053,7 +1062,7 @@ StateDirectory=aaa/bbb ccc</programlisting>
<para>This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary <para>This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary
files or directories can be still accessed by combining with <varname>BindPaths=</varname> or files or directories can be still accessed by combining with <varname>BindPaths=</varname> or
<varname>BindReadOnlyPaths=</varname>. See the example below.</para> <varname>BindReadOnlyPaths=</varname>:</para>
<para>Example: if a unit has the following, <para>Example: if a unit has the following,
<programlisting>TemporaryFileSystem=/var:ro <programlisting>TemporaryFileSystem=/var:ro