Bug 517555 - NFS4: Users should not be able to set OPEN4_SHARE_DENY_WRITE on files for which they do not have write access.
Summary: NFS4: Users should not be able to set OPEN4_SHARE_DENY_WRITE on files for whi...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.8
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: J. Bruce Fields
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-14 15:58 UTC by Sachin Prabhu
Modified: 2018-10-27 12:25 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-19 15:14:38 UTC


Attachments (Terms of Use)
Test program to recreate issue. (6.91 KB, text/plain)
2009-08-14 16:13 UTC, Sachin Prabhu
no flags Details
tcpdump showing problem. (5.84 KB, application/octet-stream)
2009-08-14 16:22 UTC, Sachin Prabhu
no flags Details
User provided proposed patch (2.43 KB, patch)
2009-08-14 17:06 UTC, Sachin Prabhu
no flags Details | Diff

Description Sachin Prabhu 2009-08-14 15:58:54 UTC
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.

Comment 1 Sachin Prabhu 2009-08-14 16:13:31 UTC
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.

Comment 2 Sachin Prabhu 2009-08-14 16:22:11 UTC
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.

Comment 3 Sachin Prabhu 2009-08-14 17:06:16 UTC
Created attachment 357481 [details]
User provided proposed patch

Comment 6 J. Bruce Fields 2010-07-19 15:08:02 UTC
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.

Comment 7 RHEL Product and Program Management 2010-07-19 15:14:38 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.


Note You need to log in before you can comment on or make changes to this bug.