linux-ext4 - Re: Extended file stat: Splitting file- and fs-specific info?

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, 09 May 2012 13:55:16 +0200
From:	Bernd Schubert <bernd.schubert@...m.fraunhofer.de>
To:	Christoph Hellwig <hch@...radead.org>
CC:	David Howells <dhowells@...hat.com>,
	Dave Chinner <david@...morbit.com>, adilger@...ger.ca,
	bfields@...ldses.org, smfrench@...il.com, ben@...adent.org.uk,
	Trond.Myklebust@...app.com, roland@...k.frob.com, jra@...ba.org,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-ext4@...r.kernel.org, linux-api@...r.kernel.org,
	libc-alpha@...rceware.org
Subject: Re: Extended file stat: Splitting file- and fs-specific info?

On 05/09/2012 01:19 PM, Christoph Hellwig wrote:
> On Wed, May 09, 2012 at 10:21:14AM +0100, David Howells wrote:
>> Dave Chinner<david@...morbit.com>  wrote:
>>
>>> I don't think we want to expose the inode generation numbers. It is
>>> trivial to construct NFS file handles (usually just fsid, inode
>>> number and generation) with that information and hence bypass
>>> security checks to access files.
>>
>> I was asked for it by Bernd Schubert for userspace NFS servers and FUSE -
>> maybe he can say what he wants it for.
>
> It's entirely broken, as a generation number might be part of the file
> handle (and for Linux-like filesystems normally is), but it's entirely
> up to the filesystem to decide how it works.  That's why we added system
> calls to do operations on opaque file handles that the file system
> controls.  Exposing a completely meaningless "generation" is a bad idea.
>

The basic idea of generation numbers is to check if an inode was 
recycled, so only if the tuple of inode-number and generation-number 
matches we still have the same file. Kernel nfs uses that and unfs3 uses 
it via EXT2_IOC_GETVERSION, which has the overhead of an additional 
syscall. Unionfs-fuse usually keeps file open, however, it might run out 
of the maximum allowed files and I plan to add a mode to close and 
re-open files as failback mode. For that the definite knowledge if a 
file/inode is still the very same and the inode was not just recycled is 
crucial.

All of that being said, I think with open_by_handle_at() syscall we 
don't need the inode generation number any more.



Cheers,
Bernd
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html