This is the mail archive of the
mailing list for the glibc project.
Re: Extended file stat: Splitting file- and fs-specific info?
- From: Bernd Schubert <bernd dot schubert at itwm dot fraunhofer dot de>
- To: Christoph Hellwig <hch at infradead dot org>
- Cc: David Howells <dhowells at redhat dot com>, Dave Chinner <david at fromorbit dot com>, adilger at dilger dot ca, bfields at fieldses dot org, smfrench at gmail dot com, ben at decadent dot org dot uk, Trond dot Myklebust at netapp dot com, roland at hack dot frob dot com, jra at samba dot org, linux-fsdevel at vger dot kernel dot org, linux-nfs at vger dot kernel dot org, linux-cifs at vger dot kernel dot org, samba-technical at lists dot samba dot org, linux-ext4 at vger dot kernel dot org, linux-api at vger dot kernel dot org, libc-alpha at sourceware dot org
- Date: Wed, 09 May 2012 13:55:16 +0200
- Subject: Re: Extended file stat: Splitting file- and fs-specific info?
- References: <20120509002420.GL5091@dastard> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20120509111958.GA11345@infradead.org>
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<firstname.lastname@example.org> 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
All of that being said, I think with open_by_handle_at() syscall we
don't need the inode generation number any more.