[RFC][PATCH 0/3] vfs: Detach mounts on unlink.

[Eric W. Biederman]

This patchset is an attempt to address two problems:
1) Not all modifications to the filesystems happen through the vfs and
   since the vfs can not cope with a mount point being unlinked or
   renamed filesystems whose modifications that do not come through the
   vfs are required to lie.

2) Through an oversight it is now possible for one unprivileged user to
   mount something on another unprivileged users dentry and make it
   impossible for the other user to unlink or rename that dentry.

It is now technically possible to easily lift the restriction on
unlinking and renaming files with mount points on them, with a
corresponding reduction in complexity of the vfs semantics and a small
code side reduction.

After thinking about it removing the restrictions on mount points
appears safe, because it is just plain dumb to have a mount point
in a directory that is not restricted to root only modifications.

This is a change in user visible semantics, so I want to be very careful
about this.  Are there any reasons to not make this change?

All of this happens under a full pile of vfs locks so this shouldn't
affect the vfs scalabilitiy work that is on-going.

Eric W. Biederman (3):
      vfs: Keep a list of mounts on a mount point
      vfs: Add a function to lazily unmount all mounts from any dentry.
      vfs: Lazily remove mounts on unlinked files and directories.

 fs/afs/dir.c           |    3 +-
 fs/dcache.c            |   80 ++++++++++++++++++++----------------------------
 fs/fuse/dir.c          |    3 +-
 fs/gfs2/dentry.c       |    4 +--
 fs/mount.h             |    3 ++
 fs/namei.c             |   31 ++++++------------
 fs/namespace.c         |   29 +++++++++++++++++
 fs/nfs/dir.c           |    5 +--
 fs/sysfs/dir.c         |    9 +-----
 include/linux/dcache.h |    3 +-
 10 files changed, 83 insertions(+), 87 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/