[systemd-bugs] [Bug 70856] PrivateTmp works incorrectly with `mount --make-rprivate /`

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=70856

--- Comment #8 from Lennart Poettering <lennart at poettering.net> ---
(In reply to comment #7)
> However, `mount --make-rprivate /` is needed to get LXC containers to work.

I don't think that is true. I have no experience with LXC, but libvirt-lxc and
systemd-nspawn have no issue with this at all. If LXC chokes on this it should
really be fixed. LXC needs to do the same as nspawn and libvirt-lxc and do the
equivalent of "mount --make-rslave /" *after* creating the container's fs
namespace, from inside of it, in order to stop propagation of mounts from the
container into the host but not vice versa.

> I mean that if service is not using `PrivateTmp` option, then any unmounts
> are propagated to the processes running inside service. Even if `mount
> --make-rprivate /` was issued before.
> 
> So, problem arises ONLY if PrivateTmp and make-rprivate using together.

Yes. That's correct. So don't use make-rprivate on root. it's incompatible with
privatetmp.

> Please, take a careful look on scenario I attached at first comment.
> 
> Unmounts are propagated:
> # mount --make-rprivate /
> # mount blahblah /mnt
> # systemctl start ntpd (without PrivateTmp option in ntpd.service)
> # umount /mnt
> 
> Unmounts are NOT propagated and unmounting /mnt CAUSES A PROBLEM:
> # mount --make-rprivate /
> # mount blahblah /mnt
> # systemctl start ntpd (WITH PrivateTmp option in ntpd.service, which is
> default)
> # umount /mnt
> 
> Hope it is clear enough...

Yeah, again, we don't support this. Either stop using PrivateTmp= or stop using
make-rprivate on root. We don't support both in combination. Sorry.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140411/ee81d212/attachment.html>