lkml.org 
[lkml]   [2008]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch 00/13] vfs: add helpers to check r/o bind mounts
From
Date
> > >  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


\
 
 \ /
  Last update: 2008-04-24 16:39    [W:0.217 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site