On Thu, May 05, 2016 at 03:48:16PM -0400, Jeff Layton wrote: > On Thu, 2016-05-05 at 10:09 +1000, NeilBrown wrote: > > On Thu, May 05 2016, Dave Chinner wrote: > > > > > > > > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote: > > > > > > > > (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. > > > > > > > > > > > > > > > > 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-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
