2012/1/7 Al Viro <viro@xxxxxxxxxxxxxxxxxx>: > On Sat, Jan 07, 2012 at 05:59:10PM +0100, Stef Bon wrote: > >> Yes you've got a point here. Absolutly, the moving of a subtree is not >> noticed by the fuse fs, and therefore cannot be taken into account. >> And yes, I agree, that the only way to deal with that is "if you do >> this with the fuse fs, strange things can happen type of warning". I'm >> happy we agree on something! > > There are almost certainly some things we agree on, but that's not > the *only* way to deal with that. "Don't use inotify" is another. Ok, but (i)notify is part of the kernel, so I do not have a choice here. One has to deal with it, if you like or not. > > And it's not just moving a subtree. mount --bind followed by umount > of the original is another obvious example. So's having per-user > namespaces, etc. > > Moreover, exact same example of a race would still apply without > mount being involved - have user pass /proc/6969/fd/42/bar/barf to > inotify_add_watch() and replace mount --move with dup2(). > > Passing the pathname is *hopeless* here. And IMNSHO so's relying on > inotify in general - it's not a general-purpose API and any program > relying on it being usable on an arbitrary part of tree is buggy. Pathname not good, what about an unique identifier per mountpoint and the inode? Stef Stef -- 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
