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

Andreas Gruenbacher
2007-08-08T21:42:09Z

On Wednesday 08 August 2007 21:25, Christoph Hellwig wrote:
> On Wed, Aug 08, 2007 at 07:16:26PM +0200, Andreas Gruenbacher wrote:
> > Create a temporary struct vfs_lookup in file_permission() instead of
> > passing a NULL value.
>
> NACK. file_permission is special in that it doesn't happen in the
> context of any kind of lookup operation, and the nd/intent paramater
> to ->permission should be NULL in that case instead of faking up some crap.

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. (Yes I
know, it doesn't do that right now. Bug.) I can't think of a better example
right now, but the intent does not only make sense in lookup context.

It's true that filesystems should never touch vfsmnts -- except for a few rare
exceptions. Filesystem stacking is one. NFS silly-rename is another: if the
vfsmnt of the object being silly-renamed were passed down to the file system,
we would mntget() it. Right now there is a reference counting bug that allows
to blow up the kernel by unmounting that mount point before the silly-renamed
file is closed. (It's client-side only of course, but still.) 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.

Last but not least, file_permission() is a vfs function not a filesystem
operation. It indirectly calls into security_inode_permission(). We need the
vfsmnt there for path-based LSMs, for operations like fchmod(2). But that's a
different set of patches, and a different discussion.

Thanks,
Andreas