Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
