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.

[pmorie]

@rootfs what is your specific use-case?

On Thu, Jul 9, 2015 at 1:12 PM, Huamin Chen notifications@github.com
wrote:

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.

—
Reply to this email directly or view it on GitHub
#56 (comment)
.

[rootfs]

@pmorie
kubernetes/kubernetes#8124 (comment)

[philips]

@mrunalp I see, this makes sense putting a flag on the mounts. Perhaps we just make the rootfs another mount to cleanup the schema. So:

"mounts": [
    {
        "type": "bundle",
        "source": "rootfs",
        "destination": "/",
        "sharing": "slave",
        "options": ""
    },

[crosbymichael]

@philips actually that option goes in the options field as just slave and rslave.

[wking]

On Thu, Jul 09, 2015 at 11:21:26AM -0700, Brandon Philips wrote:

Perhaps we just make the rootfs another mount to cleanup the schema.

I like this approach better, since it lets us avoid having two
separate structures for root mounts and other mounts (e.g. one handles
read-only explicitly, and another which handles it along with other
things in an options field). We can always fail out if the user
doesn't specify a root-destination mount. But note that things may be
a bit trickier on Windows which requires a read/write mount 1 and
may not have a native analog for “root filesystem” [2](but I'm not
familiar enough with Windows to know what the appropriate destination
path should be).

[pmorie]

@crosbymichael Hrm, I thought the options field was in the fstab format and that fstab didn't allow setting propagation modes, is it possibly a gap in the fstab spec?

[rhatdan]

fstab does not allow you to specify propagation.

[rootfs]

I used rootfsPropagation in spec.Linux rootfs/runc@b68acd7

[philips]

@rootfs I agree we should just add it to the root mount too. @crosbymichael eh?

[mrunalp]

@rootfs @philips +1, could you open a PR here to add it to the spec?

[rootfs]

@mrunalp done, see #70

[mrunalp]

@rootfs I meant a PR to change spec_linux.go in this repo :)

[wking]

Is this closable now that #71 has been merged?

[philips]

Yes, closing based on #71