Subject: Re: filehandles
To: Bill Studenmund <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 12/07/1999 15:17:42
Bill Studenmund wrote:
> On Mon, 6 Dec 1999, Simon Burge wrote:
> > I must be missing something really obvious here - don't the other
> > filehandle routines also require root privs, so it's not as if a
> > user process can do anything with a filehandle? Why does getting a
> > filehandle require root as well?
> Once you know a file's filehandle, you could create nfs requests to access
> The main reason for these restrictions is that the filehandle contains the
> generation # of the file. For security reasons, we restrict access to this
> value. _That_ is the reason getfh is restricted. :-)
Ok, let's get back to NFS. At the moment, all local filesystems for
NetBSD have u_int32_t (or smaller?) as the inode type, so the basic
stat(dev,inum) test for file equivalence works. It's only where you've
NFS mounted a remote filesystem that has > 2**32 inodes that we have a
problem, correct? From my reading of the NFS code, NFSv3 supports 64
bit fileids, so simplistically why not just make ino_t a 64 bit value?
The way disk sizes are increasing, it's something that we may have to do
sooner than later anyways...