Messages in this thread | | | Date | Wed, 14 Jul 1999 14:20:14 +0200 (CEST) | Subject | Re: NFSv3 support (bugs, some fixes, and more) | From | Trond Myklebust <> |
| |
>>>>> Michael Kaminsky <kaminsky@lcs.mit.edu> writes:
> 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/
| |