Messages in this thread | | | Subject | Re: [patch 00/13] vfs: add helpers to check r/o bind mounts | From | Miklos Szeredi <> | Date | Thu, 24 Apr 2008 16:36:38 +0200 |
| |
> > > 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
| |