Re: [RFC 04/10] Temporary struct vfs_lookup in file_permission

[Andreas Gruenbacher <agruen@suse.de>]

On Thursday 09 August 2007 01:24, Christoph Hellwig wrote:
> On Wed, Aug 08, 2007 at 11:41:06PM +0200, Andreas Gruenbacher wrote:
> > Lookup or not doesn't actually matter. Think of fchdir(2): it does a 
> > permission check, and it should also pass down the LOOKUP_CHDIR flag.
> 
> fchdir per defintion doesn't do any lookup, and it should not pretend to be
> doing one.

fchdir doesn't pretend to do a lookup by passing the LOOKUP_CHDIR flag, it 
indicates that a chdir is being done. The lookup happened earlier at a time 
at which the kernel didn't know that a chdir would follow. If fchdir doesn't 
pass down the LOOKUP_CHDIR flag, then that flag is pretty pointless: it could 
be bypassed any time by an open followed by fchdir.

> > The vfsmnt that this patch passes down in file_permission() is not some
> > crap as you chose to call it, it's the appropriate vfsmnt.
> 
> No, it's wrong.  There is no path except for informal purposes attached to
> a struct file.

I'm sorry, but the dentry and vfsmnt in struct file is *not* only used for 
informational purposes: openat does a lookup relative to a file's dentry and 
vfsmnt, and there are other examples as well.

The dentry and vfsmnt identify a particular object in the filesystem 
hierarchy. As long as the file hasn't been deleted, they can be used to 
compute a pathname that leads to the file (if the file is reachable at all). 
You can used that pathname for more than informational purposes. It is real, 
and canonical too.

> I created file_permission to document that clearly and people don't try
> things like this. There's lots of chances where fs passing has happened,

						  ^ you must mean fd passing

> were into a lazily detached tree, after a pviot_root, etc where trying to do
> anything that remotely looks like pathname based operation just doesn't make
> any sense in this case.

What you are saying doesn't make sense. It makes perfect sense to compute the 
pathname of an open file in some situations. Obviously it does not make sense 
when the file has been deleted, and you really do want to detect when a file 
has become unreachable (lazily unmounted, other namespace, whatever). You 
will always find that out when trying to compute its pathname, so that's not 
an issue. (Caveat: this requires the d_path fixes I have posted earlier.)

Thanks,
Andreas
-
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/