> > >  fh_verify() doesn't modify.
quoted text
> > > 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.

quoted text
> > > 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/