Pavel Machek <pavel@xxxxxx> writes: > On Mon 2009-03-23 14:21:30, Miklos Szeredi wrote: >> [CCs trimmed] >> >> On Mon, 16 Mar 2009, Serge E. Hallyn wrote: >> > Quoting J. Bruce Fields (bfields@xxxxxxxxxxxx): >> > > special privilege, so don't consult filesystem permissions (do I have >> > > that right? What happened to the attempt to allow ordinary users to >> > > mount?). >> > >> > Well, they keep getting stalled because we don't have a good answer for >> > what to do about the fact that an unprivileged user can make trees >> > undeletable by pinning them with mounts. (Miklos and Eric cc'd in case >> > I didn't explain that well enough). >> >> That's correct. >> >> The best answer I can come up with is to allow rmdir/unlink to >> automatically umount trees from their respective dentries. Obviously >> this can't be done for regular (privileged) mounts, which must keep >> returning EBUSY in such situations. >> >> But for unprivileged mounts I can't see any fundamental issue with >> such an approach. >> >> Does anyone see a problem with this? Is there a better solution? > > Well... traditionally if you have an open file or cwd inside mounted > tree... that blocks unmount, right? > > What will you do with processes that have open (deleted) files inside > the mount? What about cwd? That is a backwards understanding, of the problem. Currently I can not delete my mount point if I have something mounted on it in another mount namespace. Generally lazy unmounts solve the deleted inodes problem, your were talking about. Eric -- 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
