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

[Andreas Gruenbacher]

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
-
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/