Most recent kernel where this bug did not occur: unknown Distribution: gentoo (vanilla_sources) Hardware Environment: Software Environment: nfs-utils 1.0.10, vanilla-sources 2.6.19 (+ patch from http://bugzilla.kernel.org/show_bug.cgi?id=7385) Problem Description: I am able to read from and write into files on a nfs4 mount which I own as a normal user without the appropriate permissions. If I use "normal" nfs (I think it is nfs3) I can't read or write those files without the appropriate permissions (which I think is the right behviour). 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 echo "hello world" > /bla/hello chmod 0000 /bla/hello cat /bla/hello will show "hello world
Original report http://bugs.gentoo.org/show_bug.cgi?id=149493
This bug has existed since the introduction of NFSv4 to the kernel. It should be fixed by 9801d8a39cfe6c34f39f9552a246a6bd002e735e and dc730e173785e29b297aa605786c94adaffe2544, which will be in 2.6.19.
It doesn't work well. After installing the patch on the server, gnome and kde don't work anymore on nfs4 mounted homes. kde hangs during startup and gnome isn't able to create new files (although it is able to create new directories), vi has also some problems. Temporary files are created with permissions 0000 and so it is not able to read or write into those files.
The previous patch exposed another bug: we're checking open permissions against the mode even when a file was newly created by the open. Should be fixed in 2.6.19-rc3-CITI_NFS4_ALL-2, but fix may need a little more thought before going upstream. See gitweb for the individual patches: http://linux-nfs.org/cgi-bin/gitweb.cgi?p=bfields-2.6.git;a=shortlog;h=2.6.19-rc3-CITI_NFS4_ALL-2
Is this fixed in Linus' tree yet?
"Is this fixed in Linus' tree yet?" Yes, sorry, it should be fixed in 2.6.19; could you confirm?
Please reopen this bug if it's still present with kernel 2.6.20.