"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. >> 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. 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 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 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
