Most recent kernel where this bug did not occur: 2.6.18 Distribution: gentoo (vanilla_sources) Hardware Environment: Software Environment: nfs-utils 1.0.10, vanilla-sources 2.6.19 Problem Description: It is not possible to mount a nfs4 export. It fails with the error message can't read superblock. Steps to reproduce: install gentoo with vanilla-sources 2.6.19_rc1 or rc2 and nfs-utils 1.0.10 and unmask the necessary dependencies entries in /etc/export /export *(rw,fsid=0,insecure,no_subtree_check,sync) /export/bla *(rw,nohide,root_squash,insecure,no_subtree_check,async) /export/user *(rw,nohide,root_squash,insecure,no_subtree_check,async /export and /export/bla have group and owner root and chmod 0777 commands: modprobe nfs /etc/init.d/nfs start /etc/init.d/nfsmount start mount -t nfs4 127.0.0.1:/bla /bla Watch the computer hanging and then responding with an error in /var/log/messages that the server wouldn't respond and mount responding with "... can't read superblock". The problem I had why I tested the kernel was that it is possible to read and write files on an nfs4 mount as a normal user having none permissions (chmod 0000) but owning the file. But I can't test it on kernel 2.6.19 because I can't mount nfs4 exports.
Created attachment 9303 [details] NFSv4: Fix thinko in fs/nfs/super.c Known bug due to a combination of a bug in Gentoo's implementation of "mount" for NFSv4, and a kernel-side "fix" that was incorrect.
Thanks for the patch. Using the patch I was able to test my permission problem with vanilla-sources 2.6.19_rc2 and even there it exists. I'm able to read and write from and to my own files even with permissions set to 0000. Try it on a local file system (or with nfs) and you will find out that this is not the usual filesystem behaviour. So I think nfs4 has a bug regarding file permission handling. It is not a real security bug, because you can't read or write files of others without appropriate permissions, but your programs can overwrite your files without changing permissions.
That is an entirely different issue that has nothing to do with the bug you reported above. All NFS servers have traditionally implemented this policy because NFSv2 and NFSv3 are stateless (there is no protocol equivalent of open() or close()). In order to make open("foo", O_CREATE|O_WRITE, 0) work, you have to allow writing by the owner to these files. NFSv4 introduces state, and has both OPEN and CLOSE, so it can remove the 'writeable 0 mode file' hack. I believe Bruce already has a patch for this in his latest CITI_ALL series.
To clarify what I meant above: I believe a fix for the permission issue is available, but if you would still like to report it in the bugzilla, then please file it under a new entry, so that we keep it separate from the mount problem.