Linux 2.2.18 nfs v3 server bug (was: Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export)
A message that is not in the archive (sent off-list or not yet received): [email protected]
(Please consider removing FreeBSD-stable from the recipient list when replying.)
Summary:
The Linux 2.2.18 NFS v3 server returns bogus and as per RFC-1813 invalid NFS3ERR_ROFS to ACCESS procedure calls when exporting a file system read-only, when it should instead return "OK" along with the actual permissions the client has, ANDed with the permissions the client queried.
The bug is visible on FreeBSD 4.2-STABLE client which cannot ls The mounted file system (NFS v2 is fine since it does not have ACCESS). There is no related log entry in the 2.2.19pre7 change log. I did not check Linux 2.4.0, 2.4.0-acX or 2.4.1-preX either.
Quoted 4 lines · Guy Harris
Yes - for one thing, that means that if some client decides, while it's asking whether the server whether it can write to a file, to check also whether it can read from the file, it can get back an answer to both of those questions, even if the file is on a read-only file system.
Yup. Looks like a Linux kernel bug, so I'm cc'ing Alan Cox as kernel release maintainer as well as linux-kernel to make this a known issue.
I got libpcap 0.6.1 and ethereal 0.8.15 and that's what I found:
FreeBSD 4.2-STABLE sends three NFSPROC3_ACCESS requests, with 0x3f argument (meaning READ|LOOKUP|MODIFY|EXTEND|DELETE|EXECUTE), and to each, Linux 2.2.18 sends NFS3ERR_ROFS back, obj_attributes contains the stat data. ERR_ROFS is invalid here and makes indeed no sense, proper behaviour would be NFS3_OK with just READ|LOOKUP|EXECUTE set, since the server can actually access or stat the exported FS. Please correct me if I'm mistaking what RFC 1813 demands.
client: $ mount server:/space /mnt
$ ls /mnt
ls: mnt: Read-only file system
(FreeBSD 4.2-STABLE)server: $ ls -ld /space/
drwxrwxrwt 23 root root 706 Jan 2 11:53 /space/
$ grep /space /etc/exports
/space 192.168.0.0/255.255.255.0(ro)
(Linux 2.2.18, nfs-utils 0.2.1)
Signature · 5 lines
Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line · Neil Brown
freebsd-stable removed! reiserfs gone. Who goes next:-? Alan?
The bugs, I hope.
Quoted 5 lines
I stuffed up when I tried to interpret the error, but after much sensible correction, here is a patch. Please try it, and suggest any other errs that should be tested for (or maybe we should invert the sense of the test, and test for error codes that ACCESS is allowed to return.
This looks better and it makes FreeBSD able to ls the directory, and on touch /mnt/try, I get EROFS on the client, so this is okay; however, the access reply does not include EXECUTE permissions which I find strange, since the client lists this:
drwxrwxrwt 23 root wheel 706 Jan 2 11:53 /mnt
Evidently, the directory has execution permissions for everyone.
Signature · 5 lines
Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Matthias Andree
This looks better and it makes FreeBSD able to ls the directory, and on touch
/mnt/try, I get EROFS on the client, so this is okay; however, the access reply does not include EXECUTE permissions which I find strange, since the client lists this:
My fault. NFSv3 has a different permission partitioning than local file systems have, I did not see that. So Linux does the right thing for ACCESS with Neil's patch. Neil, could you submit that patch to Alan or bless it for inclusion into 2.2.19(pre)? The FreeBSD people could then sleep well again. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/