On Thu, Apr 24, 2008 at 01:39:50PM +0200, Miklos Szeredi wrote: > Then I did this series, which basically guarantees, that that cannot > happen. Al rejected it, and rather fixed some of the remaining > places. He still missed several, which sort of proves my point. Which ones have I missed? > I think it's totally pointless to continue trying to fix the symptoms > instead of getting at the root of the problem. > > I know that VFS interfaces are a sensitive question, but it would be > nice it we could have some sanity back in this discussion. Yes, it would. How about that, for starters: path_create() et.al. are *wrong* for nfsd; if nothing else, I'm not at all convinced that even apparmour wants export path + relative there _and_ r/o vs. r/w is decision that doesn't clearly map to ex_mnt flags. Moreover, it's not at all obvious that we want to drop write access as soon as vfs_...() is over in case of nfsd. Some of the stuff done immeidately afterwards might very well qualify for inclusion into protected area; some of the stuff done immediately _prior_ very likely needs that as well - look at fh_verify() and tell me why we don't want that "I'll hold write access to vfsmount" to span the area including that sucker. If we want the r/o vs r/w policy directly vfsmount-based for nfsd, that is. For ecryptfs it's also bogus - at the very least we need to decide what should happen when underlying vfsmount is remounted. Again, I'm less than convinced that we want the same way to express r/o vs. r/w policy. -- 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
