Messages in this thread | | | From | (Eric W. Biederman) | Date | Tue, 07 Oct 2014 14:26:00 -0700 | Subject | Re: [PATCH] [RFC] mnt: add ability to clone mntns starting with the current root |
| |
Andy Lutomirski <luto@amacapital.net> writes:
> Why should MNT_LOCKED on submounts be enforced? > > Is it because, if you retain a reference to the detached tree, then > you can see under the submounts?
Yes. MNT_DETACH is a recursive operation that detaches all of the mount and all of it's submounts. Which means you can see under the submounts if you have a reference to a detached mount.
> If so, let's fix *that*. Because > otherwise the whole model of pivot_root + detach will break.
I am not certain what you are referring to. pivot_root doesn't manipulate the mount tree so you can see under anything.
What I believe is the appropriate fix is to fail umount2(...,MNT_DETACH) if there are any referenced mount points being detached that have a locked submount.
> Also, damn it, we need change_the_ns_root instead of pivot_root. I > doubt that any container programs actually want to keep the old root > attached after pivot_root.
Shrug. Except for chroot_fs_refs() pivot_root is a cheap.
I'm not particularly in favor of merging pivot_root and umount2. The number of weird cases in the current api are high. A merged piece of code would just make them higher.
I am hoping that one more round of bug fixing will at least get the bugs for having unprivileged mounts fixed in the current API.
Eric
| |