On Wednesday April 9, [email protected] wrote:
> On Mon, Apr 07, 2008 at 02:43:46PM -0400, J. Bruce Fields wrote:
> > Anyone who depends on the "x" bit to control access to objects in an
> > nfs-exported filesystem is already in trouble. We could do so for
> > directories (at the expense of non-posix-like behavior such as what
> > you've seen), but we probably can't for files. So I'm inclined to think
> > this is the right thing to do.
> > The "DON'T USE THIS FUNCTION EVER, thanks." suggests we should at least
> > consult the person who added that comment (cc'd) before adding a call to
> > lookup_one_noperm(). (And if we decide to do this, we should make a
> > note of this in that comment.)
> That function really shouldn't be used and we should obey the x bit.
> And yes, due to NFSs staleless file handles this will lead to non-posix
> behaviour which is expected. The same will happen with other nfs
> servers aswell.
For the record, I disagree. I think it is perfectly appropriate to
use this function. I think that obeying the 'x' bit is wrong.
What we are doing here is reconstructing the dcache to correctly
reflect the filesystem. The reason that we need to do this (rather
than just leaving the dentry disconnected as we sometimes do with
files) is so that lock_rename can find valid d_parent pointers and can
guard against certain directory rename races that might create
i.e. the look_one_* is not being done on behalf of the owner of the
file, or of the group-owner of the file, or of anyone else. It is
being done on behalf of the filesystem to ensure future filesystem
So none of the 'x' bits (owner, group-owner, world) is appropriate to
validate this lookup.