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

From: Andreas Gruenbacher
Date: Thu Aug 09 2007 - 13:24:55 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/