Problem Description: When NFS tree is exported with restricting options (like root_squash), kernel NFS client checks permissions to device files / named fifos against remote server instead of just checking them locally (if device file is 0700 and owned by root, it should be still writable by client root processes run by root, even with root_squash) Steps to reproduce: # Create an export entry on the server: mkdir /foo mknod -m 0600 /foo/null c 1 3 echo '/foo *(all_squash,async,ro)' >> /etc/exports exportfs -ra # mount it on the client: mount server:/foo /foo echo foo > /foo/null It will result with: -su: /foo/null: Permission denied Expected behaviour: normal succesful write operation
Created attachment 12473 [details] Patch which causes nfs client to check special device permissions locally It may be dirty, I don't know linux NFS implementation thoroughly. But it shows what is the problem.
> Expected behaviour: normal succesful write operation Not in my book. NFS permissions are supposed to be checked on the server. The current behaviour is quite correct.
Could you please point me to the doc that says this? Checking permissions on server seems pointless to me, if open(), read(), write() and ioctl() are done locally. As I see it, device/fifo files permissions are always meant to be used locally...
For starters, you can RFC1813. For instance page 13 has a summary of the problem: ACCESS An ACCESS procedure has been added to allow an explicit over-the-wire permissions check. This addresses known problems with the superuser ID mapping feature in many server implementations (where, due to mapping of root user, unexpected permission denied errors could occur while reading from or writing to a file). This also removes the assumption which was made in the NFS version 2 protocol that access to files was based solely on UNIX style mode bits. It is completely irrelevant what kind of file you are trying to access and/or where the data resides (locally or remotely). The security is determined by the mode bits and/or ACLs, which reside on the server, and can only be interpreted by the server.
Sorry, but I don't understand how the fragment you have cited is relevant to the problem described in this bugreport. Why should we use ACCESS at all when dealing with devices/fifos? Permissions restrict access to data. And data is on the client in this situation. Sorry, I just see it as a horrible PITA when developing my thin client solution, that's why I am bugging you about it.
The NFS security model was decided upon by Sun over 20 years ago, and has been followed by all vendors (including Linux) ever since. We are NOT breaking expected behaviour just in order to make one application happy. As for the reason behind the model, if you read the quote carefully, you will note that the NFS security model is a _centralised_ security model that goes beyond the posix uid/gid + mode bits. It allows for the possibility that the administrator of the server may wish to map user ids, to set ACLs etc in order to limit the control exercised by untrusted users or clients on the server. In return, the client is expected to request permission from the server before allowing the user access to cached information, fifos, pipes, etc. That is the model we will continue to follow.