[systemd-devel] Docker vs PrivateTmp

Lars Kellogg-Stedman lars at redhat.com
Mon Jan 19 10:00:12 PST 2015

On Mon, Jan 19, 2015 at 08:54:52PM +0300, Andrei Borzenkov wrote:
> > What is causing this behavior? I have tried to replicate it by hand through a
> > combination of mount and unshare, and the only way I can get a mount to persist
> > in the unshare namespace after being unmounted in the global namespace is by
> > explicitly calling mount `--make-rprivate /` *inside* the unshare namespace, which
> > is obviously not happening in the above Docker example.
> > 
> It obviously happens. Your mount is private (it does not have any of
> shared/master/.. flags). May be docker does it?

I think you may not have read the above correctly...with the Docker
exmaple, I am never explicitly using "--make-rprivate" in the child
mount namespace that I create with 'unshare'.

Docker may indeed be creating private mounts, but I can't replicate
that behavior myself doing something like:

    global# mount --make-private /dev/testvol /mnt

In this case, if I create a new namespace with 'unshare -m', I see:

    unshar# grep testvol /proc/self/mountinfo
    860 749 253:16 / /mnt rw,relatime - ext4 /dev/mapper/fedora-testvol rw,seclabel,data=ordered

And if I unmount the filesystem from the global namespace:

    global# umount /mnt

It disappears from the "unshare" namespace as well:

    unshare# grep testvol /proc/self/mountinfo

If you can produce a sequence that replicates the behavior I'm seeing
with docker using just 'mount' and 'unshare' that would help
tremendously, because I'm still not entirely sure how we end up in
this state.

Lars Kellogg-Stedman <lars at redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack          | http://blog.oddbit.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150119/6ee7a2b2/attachment.sig>

More information about the systemd-devel mailing list