Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > >> > So in order for me as an unprivileged user to pin a dentry by mounting > >> > over it, I have to have write permission to the dentry to begin with > >> > as well as the dentry being under a user=hallyn mount. > >> > >> That second condition is interesting requiring write permission of the > >> dentry. I thought we had obviated the need for that when we added > >> ownership to the mounts themselves. In this case at least it shouldn't > >> it be write permission on the directory containing the dentry. > > > > Oh no, it seems I'm wrong, that's not a condition. Just tested it. > > Ok. I couldn't find Mikolos's code when I looked quickly. > What are the current rules? It sounds like my original example could apply. Rules according to permit_mount: if CAP_SYS_ADMIN, allowed if fs type is not marked safe for user mounts (and not bind), -EPERM if target is a link, -EPERM if target is labeled with new nosubmnt flag, -EPERM if target is not a user mount owned by current->uid, -EPERM if recursive bind mount, -EPERM (?) > >> This seems to mess up things like revoke. > > > > Hey, do we have revoke now? :) > > Periodically someone works on revoke ;) > > >> At a practical level it is a real annoyance, regardless of the security > >> implications. > >> > >> As a point of comparison plan9 does not have that restriction. > > > > Why doesn't it have that restriction? > > I haven't heard the reason. > > > Does it always allow you to rm a mounted-over file? > > Yes. > > The implementation of mounts in plan9 is a bit different. In > plan9 mounts are looked up by mount namespace and qid (effectively > the inode number). So the semantics are slightly different. > Requiring a new mount namespace if you want to see what a filesystem > looks like without a mount on top of a given file. > > It also looks like plan9 is likely to have a unmountable and unusable mount > if you actually delete an file, from another mount namespace. > > Linux actually has a very similar case where we can loose a mount if you rename > the directory that contains it to be somewhere higher in the mount hierarchy > than the location the mount was under. Can you give an example? > All of that said there is a very good practical justification for it all. > In a filesystem where not all changes come through our local VFS the > VFS cannot prevent changes to a filesystem it can only cache and respond > to changes that do occur. > > So things like sysfs_rename_dir and sysfs_move_dir routinely bypass > the VFS restriction against changes happening under mount points. It > isn't a problem in practice because people don't mount on sysfs but the > problem is very much there today. > > It looks to me like the right solution is very much to do the lazy > unmount we do for expired mounts, and purge everything that happens You mean if we rm something, do the same thing we do for a lazy umount? That sounds reasonble, if the implementation is doable. And should avoid any potential revoke issues for Pekka. > and then we just don't have to worry about mounts causing a denial > of service attack and life gets simpler. > > Rename is a bit trickier than unlink and rmdir in that we should allow The rename issue here being what you mentioned above about losing a mount if we mv something to the wrong place? > it on the underlying filesystem and only remove the directory if the > rename goes out of scope for the overlying mount. > > 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
