> On 12 Jul 1999 14:19:20 +0200, Trond Myklebust writes:
>> This will not work. You can't use the filehandle, since it is
>> not unique to the inode (consider hard links).
> RFC 1813 (NFSv3) says
> To the client, the file handle is opaque. The client stores
> file handles for use in a later request and can compare two
> file handles from the same server for equality by doing a
> byte-by-byte comparison, but cannot otherwise interpret the
> contents of file handles. If two file handles from the same
> server are equal, they must refer to the same file, but if
> they are not equal, no conclusions can be drawn. Servers
> should try to maintain a one-to-one correspondence between
> file handles and files, but this is not required. Clients
> should use file handle comparisons only to improve
> performance, not for correct behavior.
>> From my reading of the above, if an NFS server returns a
>> different
> file handle for two files that are hard-linked (i.e., the same
> file on the server), the client cannot assume that they are the
> same ("no conclusions can be drawn"). So, in the hard link
> case, the server should be returning the same handle (and the
> same fileid), right?
No! It should be returning the same fileid, but the file handle can be
(and usually is) different. 'No conclusions can be drawn' is just
stating that the fact that the file handles are different does not
necessarily mean that the file itself is different. Otherwise you
would conclude just that...
Look for example at what knfsd does for NFSv2:
/*
* This is the new "dentry style" Linux NFSv2 file handle.
*
* The xino and xdev fields are currently used to transport the
* ino/dev of the exported inode.
*/
struct nfs_fhbase {
struct dentry * fb_dentry; /* dentry cookie */
__u32 fb_ino; /* our inode number */
__u32 fb_dirino; /* dir inode number */
__u32 fb_dev; /* our device */
__u32 fb_xdev;
__u32 fb_xino;
__u32 fb_generation;
};
Hard-link into another directory, and the file handle will
change. This sort of thing is necessary in order to keep track of
files on a UNIX-style filesystem.
> As a somewhat related issue: what if an NFS server does export
> two different files with different handles but the same fileid?
> (Say I export / twice, the second time on a subdirectory of
> itself. It's a weird thing to do, but legal.) To the Linux
> kernel, they'll look like the same file (with the same struct
> inode) because they have the same fileid. But again looking at
> the RFC, the client shouldn't (can't) assume they are the same
> file.
The Fsid should in that case be different. That is why one should
compare both. This is the sort of problem that reexporting of
submounts introduces, and is another reason why the inode number alone
is insufficient (even under our stock NFSv2 in linux-2.x) for purposes
of distinguishing files.
> Ultimately, however, it's probably a pragmatic/security issue
> if a rogue NFS server can confuse the Linux kernel into a
> less-than-stable state by reusing fileids with different
> handles.
If you can't trust the server, you should not mount the
partition. There's millons of other neat tricks an evil server can
play in order to confuse the kernel. I don't think we really need to
care other than to make sure that we're robust against known server
bugs.
Cheers,
Trond
-
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/