linux-kernel - Re: [RFC 04/10] Temporary struct vfs_lookup in file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 8 Aug 2007 23:41:06 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org, John Johansen <jjohansen@...e.de>,
	Jan Blunck <jblunck@...e.de>, Erez Zadok <ezk@...sunysb.edu>,
	Josef 'Jeff' Sipek <jsipek@...sunysb.edu>
Subject: Re: [RFC 04/10] Temporary struct vfs_lookup in file_permission

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