[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
    > > >  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.


     \ /
      Last update: 2008-04-24 16:39    [W:0.029 / U:184.536 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site