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

[Bernd Schubert <bernd.schubert-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.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<david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.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 
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-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html