When I use "chmod 0000 /user/myname/dummyfile" as user myname (=not root) I am still able to read and write the file (execution is not possible) with nfs4. Using nfs a "Permission denied" message occurs, which would be the right thing (in my opinion). I don't know if it is a config error or a bug in nfs4 or if it is only a feature I don't understand. I'm using nfs-utils 1.0.10 and kernel 2.6.17-r5 on the server. The client uses kernel 2.6.18, but it also fails with other kernels on the client. It is not a gentoo specific bug. Debian has a similiar behaviour, but it only allows read-access, no write access with nfs4 and file mode 000. The server exports the folder in which the file is from an xfs filesystem. This is in /etc/exports: /export client(rw,fsid=0,insecure,no_subtree_check,sync) /export/user client(rw,sync,nohide,insecure,no_subtree_check) /export/group client(rw,sync,nohide,insecure,no_subtree_check) /user client(rw,sync,nohide,insecure,no_subtree_check) /group client(rw,sync,nohide,insecure,no_subtree_check)
*** This bug has been marked as a duplicate of 149396 ***
I know it is a duplicate, as I reported the problem yesterday, but as I reported two problems in one bug reported I wanted to separate it (nobody has reacted to the strange permissions bug so far, it could be that it is not good to report two problems in one bug report), so that 149369 is the crash bug and this is for the strange permissions
Please reproduce with both client and server running 2.6.18
Actually, make that the latest development kernel (currently 2.6.19-rc1)
I tried it with vanilla-sources 2.6.19_rc2. There nfs4 does not work anyhow. It hangs for a very long time and then cries: can't read superblock. In /var/log/messages I find a message that the server wouldn't respond. With gentoo-sources 2.6.17-r7 mounting works fine (I didn't check the permission problem because I know it exists). Maybe there are problems with the nfs-utils 1.0.10?
I assume network connectivity in general between these 2 systems is working on 2.6.19-rc2? Please report this connectivity problem to http://bugzilla.kernel.org and post the new URL here. It would also be worthwhile finding out if 2.6.18 had that problem or if it is a 2.6.19 regression.
I didn't actually use the original two systems. I set up nfs4 on another computer and let it be the server and the client. As it worked with 2.6.17-r7 the connection should be working (the computer can ping itself).
2.6.19_rc1 has the same problem: can't find superblock. 2.6.18 works without the mounting problem, but it doesn't handle permissions correctly. It is possible to chmod 0000 a file and then to read and to write as long as it is one's own file. If somebody else owns it, permissions are correctly checked, it is not possible to read someone else's files without having the necessary permission. I tested the vanilla-sources, because I wasn't able to find gentoo-sources 2.6.19*
vanilla-sources is good. Please file a bug about the new problem (can't find superblock) at http://bugzilla.kernel.org and point out that it is a 2.6.19 regression.
Bug posted: http://bugzilla.kernel.org/show_bug.cgi?id=7385
Created attachment 100014 [details, diff] Patch from kernel.org for the can't mount superblock problem see http://bugzilla.kernel.org/show_bug.cgi?id=7385
With 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.
Thanks, that was fast. As suggested, please file a separate bug report in the kernel bugzilla for the permissions problem so that we can keep track of patch flow.
Bug report for permission behaviour on kernel.org: http://bugzilla.kernel.org/show_bug.cgi?id=7390
Thanks, will keep an eye on that
Nice and fast.. patches: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=9801d8a39cfe6c34f39f9552a246a6bd002e735e;hp=dc730e173785e29b297aa605786c94adaffe2544 http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=dc730e173785e29b297aa605786c94adaffe2544;hp=e956edd0523b6b48ed367c63b0c82d8f4c447a58
With the git-patches included in the gentoo-sources 2.6.17-r5 on the nfs4 server nfs4 behaves as expected, chmod 0000-files can't be read or written anymore until the permissions are changed. Thanks for the patches. Maybe they could be included in the gentoo-sources-tree so that they will automatically installed with emerge gentoo-sources.
Please don't close bugs until the fix is included in portage
Doesn't work well with gnome and mc (and maybe other programs) ... (see kernel.org)
Not sure what i'm supposed to be looking at.. I can't see anything new on those bug reports
(In reply to comment #20) > Not sure what i'm supposed to be looking at.. I can't see anything new on those > bug reports > Sorry I had forgotten to pass the authentication on bugzilla.kernel.org. Here comes the problem: 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.
will wait for the fix to go upstream
