Extended file stat: Splitting file- and fs-specific info?
bernd.schubert at itwm.fraunhofer.de
Wed May 9 05:55:16 MDT 2012
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 at fromorbit.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
All of that being said, I think with open_by_handle_at() syscall we
don't need the inode generation number any more.
More information about the samba-technical