Re: [patch] EXT2 inode.i_generation patch

G. Allen Morris III (gam3@harpo.ixlabs.com)
Mon, 15 Mar 1999 21:39:58 -0800


>>>Chris Wedgwood said:
> On Mon, Mar 15, 1999 at 04:13:27PM -0800, G. Allen Morris III wrote:
>
> > This patch modifies the ext2 filesystem so that it uses the new
> > inode.i_generation field. No data structures where hurt in the
> > making of this patch. Some names where changed to protect
> > future maintainers.
> >
> > BUGS: There is a 1/(2^32) chance of not getting a new generation
> > number on for a new inode.
>
> Seriously, is this rarely such a rare event on a large busy server?
> Isn't this likely to occur ever now and then?

The inode also has to be the same and one of the nfs clients
has to have the file `open'. So it does seem remote.

>
> I don't understand why this is necessarily better. get_random_bytes
> is a comparatively expensive operation compared to a simple
> increment... what do we gain with this?
>

The reason that you want to get a random number is to make it
harder for someone to guess it. If you can't guess the inode/
generation number you can't access the file.

I must say you are right about the expense of get_random_bytes().
However if you don't seed the i_generation number each time then
you get very little security from the i_generation numbers and
they should only be used for correctness.

The reason is that you can set up a daemon that creates a file and
then deletes it in a loop looking at the inode after each create.
If the inode is different then it knows that someone created a file
and you also know the filehandle for that file. This is not a problem
at the moment because we check the permissions on the path to a file.
However many people would like to see linux nfs behave more like
other nfs implementations.

I would appreciate more input on this.

Allen

---------------------------------
G. Allen Morris III

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/