> > > fh_verify() doesn't modify. > > > It does check, though, and later we have that check duplicated by > > > will_write/wont_write pair bracketing a part of sequence. > > > > So what? All the other checks are also duplicated within > > vfs_create()->may_create()->permission(). > > RTFS. permission() doesn't do "is that vfsmount read-only" checks, exactly > because it's 100% bogus - either you cover it with entire area where we > are guaranteed to stay r/w, or it's by definition racy. I know that. That does not mean, that fh_verify() needs to do vfsmount r/o checks. AFAICS it's perfectly OK to do that later, around the vfs_ call. > > > ecryptfs should not use the bloody vfsmount, for fuck sake! You are > > > confusing access to fs with access to fs via specific vfsmount. And > > > pretending that the latter is fundamental operation. > > > > Umm, isn't it? Want to redo open() without a vfsmount? > > FWIW, I'm not all that happy about the way ecryptfs_interpose() is done, > while we are at it. We get the sucker opened by whoever steps on given > place in the tree first, with subsequent operations done using the resulting > struct file. With fallback to r/o open. What happens to somebody who > tries to open it with enough permissions to do r/w? You are digressing from the subject. Yes it would be nice to fix ecryptfs to be less broken. But that's not what this patchset is set out to do. Miklos -- 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
