Hide Forgot
Users who do not have write access on a file should not be able to open files with share_deny set to OPEN4_SHARE_DENY_WRITE. The test below is performed using a program which crafts packets in NFS4 protocol format and sends it to the NFS server. The credentials on the NFS packets set UID/GID to 1/1. The program attempts to open file /tmp/CID1 on the share to which the user doesnt have write access share with share_deny set to OPEN4_SHARE_DENY_WRITE. Reproducer: Server: [root@vm11 export]# uname -a Linux vm11 2.6.9-89.5.ELsmp #1 SMP Mon Jul 6 22:02:51 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [root@vm11 export]# cat /etc/exports /export *(rw,insecure,fsid=0,no_root_squash) Client: [root@vm22 ~]# uname -a Linux vm22 2.6.18-156.el5.jtltest.78 #1 SMP Mon Jul 6 10:02:12 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [root@vm22 ~]# mount -t nfs4 vm11:/ /mnt/ [root@vm22 ~]# cd /mnt [root@vm22 mnt]# mkdir tmp; touch tmp/CID1;chmod 644 tmp/CID1 [root@vm22 mnt]# gcc -o open_share_deny_write open_share_deny_write.c [root@vm22 mnt]# ./open_share_deny_write vm11 =============== FAIL ============================= trying to deny write permissions to others when don't have write permissions should return NFS4ERR_ACCESS instead got NFS4_OK. Expected Results: # ./open_share_deny_write vm22 =============== PASS ============================= trying to deny write permissions to others when don't have write permissions return NFS4ERR_ACCESS. This problem doesn't appear on RHEL 5.
Created attachment 357473 [details] Test program to recreate issue. Test program to recreate issue. This crafts the nfs packets required to open a file /tmp/CID1 as user with uid/gid set to 1/1. It sets share_deny to OPEN4_SHARE_DNEY_WRITE when opening the file.
Created attachment 357479 [details] tcpdump showing problem. Open call with share_deny set to OPEN4_SHARE_DNEY_WRITE in packet 33. Respons to the call in packet 34.
Created attachment 357481 [details] User provided proposed patch
First, why rewrite a pynfs test in C? At least for me, a pynfs test ID would be fine. Second, the described bug isn't actually one--pynfs is wrong here, and Windows (the original source of these share locks) actually does allow the DENY in this situation. That said, the *patch* may actually be correct. It appears to be a combination of upstream commits 7fc90ec9 and d1bbf14. (Please, always provide pointers to upstream commits when available.) Those patches fix a failure to enforce file permissions correctly. The problem should be restricted to filesystems exported over NFSv4. NAK'ing for now. If we think the patch should be applied, create a new bug with a description of the actual bug that the patch fixes.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.