On Thu, May 05, 2016 at 03:48:16PM -0400, Jeff Layton wrote:

On Thu, 2016-05-05 at 10:09 +1000, NeilBrown wrote:

quoted

On Thu, May 05 2016, Dave Chinner wrote:

quoted

On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote:

quoted

 (4) File creation time (st_btime*), data version (st_version), inode
     generation number (st_gen).

     These will be returned if available whether the caller asked for them or
     not.  The corresponding bits in st_mask will be set or cleared as
     appropriate to indicate a valid value.

IMO, exposing the inode generation number to anyone is a potential
security problem because they are used in file handles.

"security through obscurity".  We have Kerberos working really nicely
for NFS these days.  Do we still care?

What if the generation number were only made available to "root"?  Would
that allay your concerns?
Would that still be useful?
We already have name_to_handle_at().  Exposing the generation number
could/should follow the same rules at that.  Or maybe the exposure of
each field should be guided by the filesystem, depending on (for
example) whether it is used to provide uniqueness to the filehandle.

quoted

quoted

     If the caller didn't ask for them, then they may be approximated.  For
     example, NFS won't waste any time updating them from the server, unless
     as a byproduct of updating something requested.

I would suggest that exposing them from the NFS server is something
we most definitely don't want to do because they are the only thing
that keeps remote users from guessing filehandles with ease....

Given that the NFS protocol does not define a "generation number"
attribute, I think there is no risk for them being exposed from the NFS
server ... except implicitly within the filehandle of course.

NeilBrown

I don't see a real attack vector here either, but OTOH is there a
potential user of this at the moment? An earlier chunk of the patch
description says:

(7) Inode generation number: Useful for FUSE and userspace NFS servers
     [Bernd Schubert].  This was asked for but later deemed unnecessary
     with the open-by-handle capability available

...the last bit seems to indicate that we don't really need this
anyway, as most userland servers now work with filehandles from the
kernel.

Maybe leave it out for now? It can always be added later.

Sounds like a good compromise to me!

That said, filehandles can never be changed, and generally have to be
exposed on the network, so I don't think it's worth going to great
lengths to try keep them secret.

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