> 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.
OK, I'll agree that is remote, but the pedantic wimp in me would
still like to see this 2^(-32) probability considerably lower... it
does seem conceivable somewhere sometime in the world, this will
occur.
Also, this is for each file open is it not? Doesn't that drastically
increase the probability of getting collisions? (I don't really
understand the intricacies involves here, so I'm not clear on whether
or not this is more or less linear or otherwise).
> 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.
32 `random' bits isn't a whole lot of security IMO.
> 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.
Can you not seed it once every 100 times and use a LFSR in between?
Arguably, get_random_bytes could do/should this for us or perhaps we
have a get_weak_random bytes for this purpose.
> 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.
OK
> 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.
I'm going to cc' this to Colim Plumb as he often has good comment to
make about such things....
-cw
-
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/