It should be possible to set the mount propagation modes for containers and volumes

[pmorie]

Propagation modes determine how mount and umount events propagate between a mount namespace and its parent. The 'shared' and 'slave' propagation modes are critical to implementing use-cases where a container performs a mount that should be visible to other containers.

Currently the configuration spec lacks any way to specify the propagation mode of a mnt namespace relative to the host's mount namespace, or any indication of what the default propagation mode is. Perhaps this should be an option you can specify in the 'namespaces' config section.

@mrunalp @rhatdan @rootfs

[rhatdan]

I agree. We have talked about two different things here though. One would be to set the default for the daemon so that distributions could choose the default for all containers. Red Hat Distributions would choose SLAVE as the default, since I believe this would cause the least surprise for administrators.

The second flag would be per container. (Although some have suggested per volume mount, which I think might be too complicated, for little added value.)

[pmorie]

@rhatdan Yeah, my description was a little imprecise. I think everything on the table is:

1. Set default propagation mode for every volume of all containers
2. Set default propagation mode for every volume of a single container
3. Same as 2 except you can control the propagation mode of each volume's mount point

Completely agree that SLAVE is a reasonable default -- it jives with what the intuitive behavior of volumes should be if someone is unaware of propagation modes.

I really don't think setting a default for all containers is a great idea outside of a distributor making a call on the default policy, in part because I don't think most users are aware enough of this feature to fully reason through all the effects. From the least-privilege principle, it seems like a bad idea to configure SHARED as a default, for example, but I could easily see someone setting this as a system-wide default in order to get a single container to work.

[philips]

Yes, it seems like the namespaces list will need an additional parameter. And this parameter needs to be invalid if a "path" is given. Could someone work up a PR against https://github.com/opencontainers/specs/blob/master/config-linux.md#linux-namespaces and spec_linux.go?

[mrunalp]

@philips This could be a property of the root mount like here opencontainers/runc#77 if we don't see a need per mount.

[pmorie]

@mrunalp what's 'root mount' in the context of your comment?

[rootfs]

rootfs mount propagation

[rootfs]

IMO we need flags for both rootfs and volume propagation flags to ensure things work as expected. For example, a PRIVATE propagation for rootfs negates SLAVE or SHARED volume. Such surprise should be avoided.

[pmorie]

@rootfs Interesting point -- I probably need to do some more detailed experimenting, but I had thought that the if the mountpoint for the container's rootfs was private, that individual mountpoints with other modes (ie, /var/lib/kubelet with mode shared) would be allowed. Am I missing something?

[rhatdan]

Currently the way the mount point propogation is being done is to do a make-rprivate, on / on the host, which basically prevents any other propogation on volume mounts from working. If the make-private happened at the ROOTFS this would work. I have suggested this change but have not heard back if this fixed the problem that caused @crosbymichael to revert the change in the first place.

[rootfs]

That's because the propagation is recursive (MS_REC). So if you make rootfs private, it recursively makes all directories underneath private. Even you flip it to slave or shared, private flag still remains (there is no way you can remove a propagation mode).

[rhatdan]

Right but rootfs would make mountpoints under /var/lib/docker/... private not everything under /, which is the current behaviour. If I just did this to /var/lib/docker/... I could later mount in /var/lib/foobar into a container and changes it propogation mode.

[pmorie]

@rootfs

That's because the propagation is recursive (MS_REC). So if you make rootfs private, it recursively makes all directories underneath private. Even you flip it to slave or shared, private flag still remains (there is no way you can remove a propagation mode).

Under the fedora build of docker 1.6, I see both propagation modes from findmnt, but it still works as I expect (slave):

$ docker exec -it 36e findmnt /var/lib/kubelet -o TARGET,PROPAGATION | grep kubelet
/var/lib/kubelet private,slave

So, is that really an issue?

[rootfs]

it is probably working for your use case, but it breaks mine. I am more interested in shared, i.e. making container mounted directories also visible on the host. Once a shared directory is contaminated with slave or private, that visibility gets lost.