Way back in October Andrey Vagin reported that umount(MNT_DETACH) could
be used to defeat MNT_LOCKED. As I worked to fix this I discovered
that combined with mount propagation and an appropriate selection of
shared subtrees a reference to a directory on an unmounted filesystem is
not necessary.
That MNT_DETACH is allowed in user namespace in a form that can break
MNT_LOCKED comes from my early misunderstanding what MNT_DETACH does.
To avoid breaking existing userspace the conflict between MNT_DETACH and
MNT_LOCKED is fixed by leaving mounts that are locked to their parents
in the mount hash table until the last reference goes away.
While investigating this issue I also found an issue with
__detach_mounts. The code was unnecessarily and incorrectly triggering
mount propagation. Resulting in too many mounts going away when a
directory is deleted, and too many cpu cycles burned while doing that.
For those who like to see everything in a single tree the code is at:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing
Eric W. Biederman (11):
mnt: Improve the umount_tree flags
mnt: Don't propagate umounts in __detach_mounts
mnt: In umount_tree reuse mnt_list instead of mnt_hash
mnt: Add MNT_UMOUNT flag
mnt: Delay removal from the mount hash.
mnt: Factor out __detach_mnt from detach_mnt
mnt: Simplify umount_tree
mnt: Remove redundant NULL tests in namespace_unlock
mnt: On an unmount propagate clearing of MNT_LOCKED
mnt: Don't propagate unmounts to locked mounts
mnt: Honor MNT_LOCKED when detaching mounts
fs/namespace.c | 152 +++++++++++++++++++++++++++++++-------------------
fs/pnode.c | 60 +++++++++++++++++---
fs/pnode.h | 7 ++-
include/linux/mount.h | 1 +
4 files changed, 154 insertions(+), 66 deletions(-)
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
