[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120509111958.GA11345@infradead.org>
Date: Wed, 9 May 2012 07:19:58 -0400
From: Christoph Hellwig <hch@...radead.org>
To: David Howells <dhowells@...hat.com>
Cc: 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,
bernd.schubert@...m.fraunhofer.de, 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 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.
--
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
Powered by blists - more mailing lists