lkml.org 
[lkml]   [2016]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/6] statx: Add a system call to make enhanced file info available
[ 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

\
 
 \ /
  Last update: 2016-05-09 04:01    [W:0.113 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site