rootfs mount propagation cannot be restored to rslave after being made private in prepareRootfs

[xujihui1985]

Description

While testing mount propagation with runc, I noticed that rootfs propagation behaves incorrectly when the intended propagation is rslave.

During container setup, prepareRootfs() first changes the rootfs mount propagation to MS_PRIVATE | MS_REC, and after pivot_root, it attempts to restore the user-specified propagation.

Relevant code:
https://github.com/opencontainers/runc/blob/main/libcontainer/rootfs_linux.go#L1052

This works correctly when the intended propagation is rshared, but does not work for rslave.

Steps to reproduce the issue

1. create a container with rootfsPropagation=rslave
   1.1 nerdctl run -d --mount type=bind,src=/mnt,dst=/app,bind-propagation=rslave --entrypoint sleep 600
   1.2 verify container spec is rootfsPropagation=rslave

2. exec into container check if rootfs mount propagation is rslave 3. we expect to see the mount propagation is rslave which is rprivate

Describe the results you received and expected

we expect to see the mount propagation is rslave, which should be same if mount propagation is rshared

What version of runc are you using?

affect version from 1.3.1 to 1.5.1-rc

Host OS information

No response

Host kernel information

No response

[xujihui1985]

from kernel doc https://docs.kernel.org/filesystems/sharedsubtree.html

Slave mounts

A slave mount is defined as a vfsmount that receives propagation events and does not forward propagation events.

A slave mount as the name implies has a master mount from which mount/unmount events are received. Events do not propagate from the slave mount to the master. Only a shared mount can be made a slave by executing the following command:

mount --make-slave mount

the reason for this is a slave mount must have a master shared peer group, a private mount has no peer group and no master, so to make a mount slave from private is a no op.
I think this breaks the current volume mount propagation. When using HostToContainer mount propagation, the rootfs propagation is expected to be rslave so that we can remount the mount point. If it is private, that won’t be possible.

[xujihui1985]

@AkihiroSuda Hi, could you please take a look at this issue? If it is confirmed to be a defect, I would like to submit a PR to fix it.

[lifubang]

If it is confirmed to be a defect, I would like to submit a PR to fix it.

In theory, this appears to be a bug -- but I’m not sure if it actually affects any real-world use cases. Could you share some scenarios where this might cause issues?
Please feel free to submit a PR that includes an integration test. Thanks!

[xujihui1985]

If it is confirmed to be a defect, I would like to submit a PR to fix it.

In theory, this appears to be a bug -- but I’m not sure if it actually affects any real-world use cases. Could you share some scenarios where this might cause issues? Please feel free to submit a PR that includes an integration test. Thanks!

Hi, @lifubang A real-world use case for this is a CSI driver that mounts a FUSE mount point and relies on HostToContainer propagation to make it visible inside the container’s mount namespace. For example, with lxcfs, the process may be OOM-killed in some situations. In such cases, we expect to remount the mount point from the host, allowing the change to propagate into the container and restore the mount. However, if the root filesystem is set to private, this propagation will not occur, making it impossible to recover the mount point in any way.