Hi Reepca,

Reepca Russelstein <reepca@russelstein.xyz> skribis:

> I still think it would be a good idea to call unshare to create an extra
> user and mount namespace just before executing the builder in the
> unprivileged case, just to be sure that the mount-locking behavior is
> triggered in a way that is documented.

For some reason, it’s not working as advertised: mounts are seemingly
not locked together and umount(2) on one of them returns EPERM (instead
of EINVAL).  I suspect chroot, pivot_root, & co. spoil it all.

Attached is a patch and test case.

To be sure, I wrote a minimal C program: umount returns EINVAL as
expected.  However, when compiling it with -DWITH_CHROOT, unshare(2)
fails with EPERM because “the caller's root directory does not match the
root directory of the mount namespace in which it resides” (quoting
unshare(2)).

So I now get the idea of “locked mounts” but I’m at loss as to how this
is supposed to interact with chroots.

Thoughts?

Ludo’.