Re: another mount issue on jessie
On 02/09/2016 12:03 PM, Bas Wijnen wrote:
On Tue, Feb 09, 2016 at 10:38:26AM -0700, Sebastian Kuzminsky wrote:
On another Jessie machine I had to apply the same workaround to
some additional services. I identified the services that needed
the workaround by grepping for 'PrivateTmp' in /lib/systemd.
So any program that uses this option is broken? Doesn't that mean we
should always disable it? Is there a reason that it is ever enabled
for anything?
According to the systemd.exec(5) manpage:
PrivateTmp= Takes a boolean argument. If true, sets up a new file
system namespace for the executed processes and mounts private /tmp
and /var/tmp directories inside it that is not shared by processes
outside of the namespace. This is useful to secure access to
temporary files of the process, but makes sharing between processes
via /tmp or /var/tmp impossible. If this is enabled, all temporary
files created by a service in these directories will be removed after
the service is stopped. Defaults to false. It is possible to run two
or more units within the same private /tmp and /var/tmp namespace by
using the JoinsNamespaceOf= directive, see systemd.unit(5) for
details. Note that using this setting will disconnect propagation of
mounts from the service to the host (propagation in the opposite
direction continues to work). This means that this setting may not be
used for services which shall be able to install mount points in the
main mount namespace.
So it sounds useful and valuable, and I can see why people want it
turned on.
FWIW, these services all work without Simon's workaround if I use the
Stretch kernel (on the Jessie userspace). Only with the Jessie and
Wheezy kernels is the workaround needed.
Possibly a kernel patch could be backported to Jessie (and
Wheezy), then the PrivateTmp could be used on Jessie without hassle.
--
Sebastian Kuzminsky
Reply to: