From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750978AbcEIBpv (ORCPT ); Sun, 8 May 2016 21:45:51 -0400 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:39811 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750901AbcEIBpt (ORCPT ); Sun, 8 May 2016 21:45:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BsHQCD6i9XMZQ5LHlegziBUoZsnXoGjBqFb4QThgoEAgKBH00BAQEBAQEHAQEBAQFBQEEBAQMHBoNuAQEBAwE6HCMFCwgDGAklDwUlAwcaExmICge+FAEBCAIeGYU/hRSEKYVTHAWYIothgjGCCo0XjzuEXyoyggyCY4QXAQEB Date: Mon, 9 May 2016 11:45:43 +1000 From: Dave Chinner To: "J. Bruce Fields" Cc: David Howells , linux-fsdevel@vger.kernel.org, linux-afs@vger.kernel.org, linux-nfs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available Message-ID: <20160509014543.GS18496@dastard> References: <20160429125736.23636.47874.stgit@warthog.procyon.org.uk> <20160429125743.23636.85219.stgit@warthog.procyon.org.uk> <20160504225601.GZ26977@dastard> <20160506182923.GB13350@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160506182923.GB13350@fieldses.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ OT, but I'll reply anyway :P ] On Fri, May 06, 2016 at 02:29:23PM -0400, J. Bruce Fields wrote: > On Thu, May 05, 2016 at 08:56:02AM +1000, Dave Chinner wrote: > > In the latest XFS filesystem format, we randomise the generation > > value during every inode allocation to make it hard to guess the > > handle of adjacent inodes from an existing ino+gen pair, or even > > from life time to life time of the same inode. > > The one thing I wonder about is whether that increases the probability > of a filehandle collision (where you accidentally generate the same > filehandle for two different files). Not possible - inode number is still different between the two files. i.e. ino+gen makes the handle unique, not gen. > If the generation number is a 32-bit counter per inode number (is that > actually the way filesystems work?), then it takes 2^32 reuses of the > inode number to hit the same filehandle. 4 billion unlink/create operations that hit the same inode number are going to take some time. I suspect someone will notice the load generated by an attmept to brute force this sort of thing ;) > If you choose it randomly then > you expect a collision after about 2^16 reuses. I'm pretty sure that a random search will need to, on average, search half the keyspace before a match is found (i.e. 2^31 attempts, not 2^16). > > > 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.... > > The first line of defense is not to depend on unguessable filehandles. > (Don't export sudirectories unless you're willing to export the whole > filesystem; and don't depend on directory permissions to keep children > secret.) Defense in depth also says "don't make it easy to guess filehandles" because not everyone knows this is a problem. In many cases, users may not even know what consitutes a "filesystem" because their NFS server appliance only defines "exports". The underlying implementation may, in fact, be "everything exported from a single filesystem" and so the user has no choice in the matter.... Dave. -- Dave Chinner david@fromorbit.com