On Fri, Oct 4, 2013 at 3:41 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>
> 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?
At least one worry: people are very used to 'rmdir()' not removing
empty directories, and I've written code myself that just does an
'rmdir()' without worrying about it. I think git has code like "remove
file, then try to remove directory file is in, and recurse until it
fails or you hit the top of tree". And it all depends on knowing that
rmdir() is harmless, and returns the appropriate error when the
directory isn't empty.
And you're now changing that. If it's a mount-point, the rmdir just
succeeds, afaik.
Does anybody care? I dunno. But it looks like a _big_ semantic change.
That said, I like the _concept_ of being able to remove a mount-point
and the mount just goes away. But I do think that for sanity sake, it
should have something like "if one of the mounts is in the current
namespace, return -EBUSY". IOW, the patch-series would make the VFS
layer _able_ to remove mount-points, but a normal rmdir() when
something is mounted in that namespace would fail in order to give
legacy behavior.
Hmm?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
