config-linux: improving description about rootfs mount propagation

[dongsupark]

Recently I had a look into the rootfs mount propagation section in the spec, with @alban and @iaguis. I think there's a room for improvement in the section.

First of all, the description Its value is either slave, private, shared or unbindable is not exactly correct, because it can be also slave and shared. Is it ok to add a new mode for slave+shared in the spec?

I think the section needs some additional explanation with general idea about mount propagation, at least in one paragraph. Currently it simply points to the shared subtrees document in the Linux kernel, which is not exactly readable for all readers. Is it ok to add some explanation in the section of runtime-spec?

I'm aware that there have been issues regarding the topics, for example #923. Though I'm not sure what the general consensus is.

[alban]

Also, the value 'shared' by itself is not clear. It could mean

1. 'shared' with the mount in the host namespace, or
2. 'shared' (i.e. /proc/$pid/mountinfo would show 'shared:xx') but alone in its mount peer group.

IMO the second is useful for example when doing nested containers. I don't see the point of the first.

[cyphar]

is not exactly correct, because it can be also slave and shared.

I'm not sure what you mean by this -- according to mount(2) you can only have one propagation type for any given mount:

If mountflags includes one of MS_SHARED, MS_PRIVATE, MS_SLAVE, or MS_UNBINDABLE (all available since Linux 2.6.15), then the propagation type of an existing mount is changed. If more than one of these flags is specified, an error results. [emphasis mine]

There's also the point that slave and shared have precisely opposite effects when it comes to propagation of mounts and unmounts underneath the mount (in slave they do not propagate, in shared they do) and the behaviour with the master peer group is the same. So I'm a little confused what shared+slave would actually do.

[dongsupark]

@cyphar I mean this section in the Kernel document.

A vfsmount can be both shared as well as slave. This state indicates that the mount is a slave of some vfsmount, and has its own peer group too. This vfsmount receives propagation events from its master vfsmount, and also forwards propagation
events to its 'peer group' and to its slave vfsmounts.

A real world example: https://github.com/rkt/rkt/blob/v1.30.0/stage1/init/init.go#L710..L720

[cyphar]

Ah sorry, I wasn't aware of that. In that case, yeah we probably should have a mountPropagation option to specify shared+slave.

[flx42]

As far as I can tell from the runc code, it also accepts the recursive variants rshared, rslave, rprivate and runbindable, but they are not listed as acceptable values today.

Also, the default of runc (since rootPropagation is OPTIONAL) seems to be rslave, which is mildly surprising. Should it be documented too?

[tianon]

The kernel document (at https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) is unfortunately light on how one would actually implement shared+slave
(or slave+shared? the kernel doc is pretty ambiguous on which order they should be conceptualized in and uses them both ways as "shared and slave" and "slave and shared", but more times as "shared and slave"? wget -qO- 'https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt' | grep -iE '(slave|shared) and (slave|shared)')

This is all it has to say on how to make a mount with this property (that I can see):

	Only a slave vfsmount can be made as 'shared and slave' by
	either executing the following command
		mount --make-shared mount
	or by moving the slave vfsmount under a shared vfsmount.

So I guess for me, it would be important to see/know what this actually means for implementors (like, in terms of how https://github.com/opencontainers/runc/blob/13b1603fd0e37db1764433a140d494b2e9f05805/libcontainer/specconv/spec_linux.go#L39-L49 would have to change to support it, for example) before we consider adding this new value. Would that just be unix.MS_SHARED | unix.MS_SLAVE? Are there any other combinations that make sense? Is there such a thing as a recursive version of this (and what does that mean)?