End-users may not understand who are "us", as they don't execute runc directly.

We may linkhttps://github.com/opencontainers/runc/issues for explicitness, but we may potentially get a report about some third-party product that we have never heard of.

We already provide a link to the tracking issue for this deprecation if you pass--no-pivot (regardless of whetherpivot_root(2) works), I don't think we need to provide the same link twice?

Need the same change forcreate.go.

The (slightly more bold) alternative is to make the option hidden (in this case the description can be removed).

I was thinking of hiding it for1.3.0 but keeping it visible for1.2.z. I've added a new patch deprecating it, and I'll exclude that from the backport.

There are six reasons will cause-EINVAL:

       EINVAL new_root is not a mount point.       EINVAL put_old is not at or underneath new_root.       EINVAL The current root directory is not a mount point (because              of an earlier [chroot(2)](https://man7.org/linux/man-pages/man2/chroot.2.html)).       EINVAL The current root is on the rootfs (initial ramfs) mount;              see NOTES.       EINVAL Either the mount point at new_root, or the parent mount of              that mount point, has propagation type MS_SHARED.       EINVAL put_old is a mount point and has the propagation type              MS_SHARED.

This PR tries to deal with the forth one, does this pr would cause some unexpected behaviors for the fifth one? (Maybe need to check once have a time)
The user case:
For docker, containerd, kubernetes, the rootfs is always mount as a overlay fs, it will always be changed asMS_PRIVATE by runc, but the parent mount of rootfs may have propagation type MS_SHARED.
Before this patch, it will return an error immediately, but after this patch, it will do some magic operation to letpivot_root(2) work, I think we should be careful.

The user case:
For docker, containerd, kubernetes, the rootfs is always mount as a overlay fs, it will always be changed asMS_PRIVATE by runc, but the parent mount of rootfs may have propagation type MS_SHARED.

For this case, this patch has the same security issue like--no-pivot, even this flag is not provided. I can escape from the container.
So, I think we should split this PR into two:

1. Deprecate the flagno-pivot, this should be inmilestone 1.2.1;
2. Find a new way to handle initramfs case, this one can be moved to the next version if we can't fix it in a short time.

For this case, this patch has the same security issue like --no-pivot, even this flag is not provided. I can escape from the container.

How? Afterpivot_root(2) the whole host mount tree is gone, no?chroot_fs_refs should move thecurrent->fs->root to thepivot_root(2)'d path so the intermediatechroot(2) should not have any effect on the final mount setup AFAICS. Can you share a reproducer?

For docker, containerd, kubernetes, the rootfs is always mount as a overlay fs, it will always be changed as MS_PRIVATE by runc, but the parent mount of rootfs may have propagation type MS_SHARED.

We also set the parent toMS_PRVIATE inrootfsParentMountPrivate. (It already should not be the case that we get-EINVAL for that reason because we explicitly make sure that it works withrootfsParentMountPrivate.) Is that not sufficient?

The bind-mount of/ keeps the propagation settings the same as well. So if the propagation was actually wrong, the secondpivot_root(2) would still fail. I also don't see how you could use that to break out of the container -- AFAIK the reason the kernel requires the mount to be!shared is so that the mount tree changes duringpivot_root(2) don't propagate to the host (and break it).

Find a new way to handle initramfs case, this one can be moved to the next version if we can't fix it in a short time.

The "magic" done is just creating a bind-mount of the root that can be used forpivot_root(2) (in anMS_PRIVATE mount so the mount itself will beMS_PRIVATE, to answer your question).

This is the only way of doing it (I spoke to the VFS maintainers a few weeks ago, and this is the only "right" way of doing it -- FWIW Lennart implied that systemd does thisbut they don't it seems).

It's a bit hard to understand what the problem is without an actual reproducer.

Deprecate the flag no-pivot, this should be in milestone 1.2.1;

We can't deprecate it without having a solution for minikube and kata...

We can't deprecate it without having a solution for minikube and kata...

Mark it deprecate not means we remove it right now, it's only to remind users that they should not use it except there is no way to run their case, and to inform users that we can't guarantee the container's security with--no-privot.
But yes, it's a little strange do it in the situation that we still have no solution for minikube and kata or other projects. I think we can find a solution to fix it. I suggest to split into two because maybe we need more time to find out this solution, but I think we should releasev1.2.1 ASAP, then we can let runcv1.2.* could be tested by more and more users, especially in some downstream rc versions.

We also set the parent toMS_PRVIATE inrootfsParentMountPrivate. (It already should not be the case that we get-EINVAL for that reason because we explicitly make sure that it works withrootfsParentMountPrivate.) Is that not sufficient?

No. I have concern about it for a long time after#4417 merged, the commit is:13a6f56. This commit has changed the behavior ofrootfsParentMountPrivate:
1. Before this commit, we make/ toMS_PRIVATE mount;
2. After this commit, if therootfs is a overlay mount, we will only makerootfs toMS_PRIVATE mount.
@kolyshkin I don't know this behavior change will cause some issues, but we will not set parent toMS_PRIVATE is a fact, but maybe makerootfsMS_PRIVATE is enough.
EDIT: Sorry, I'm wrong, the parent mount point has always been changed toMS_PRIVATE byrootfsParentMountPrivate; So this bug is not related to this, I have sent the email to@cyphar, if you don't receive it, please let me know.

It's a bit hard to understand what the problem is without an actual reproducer.

I'll send you a email ASAP.