Red Hat Bugzilla – Bug 1415780
File permissions are not getting set as expected on nfs v4.0 mount
Last modified: 2017-08-02 01:10:53 EDT
Created attachment 1243729 [details] Customer's reproducer program Description of problem: When opening a file with O_WRONLY|O_CREAT|O_EXCL flags, and umask of 0022, a customer reports that the resulting file permissions are as expected with the 3.10.0-327.el7 kernels (RHEL 7.2), but are incorrect with the 3.10.0-514.el7 kernel (RHEL 7.3) Issue began after upgrade from RHEL 7.2 to 7.3 Version-Release number of selected component (if applicable): RHEL 7.x, kernels: 3.10.0-327.36.3 - okay 3.10.0-327.44.2.el7 - okay 3.10.0-514.2.2.el7 - bad nfs v4.0 mount from NetApp, OnTap version 8.2.4P5 How reproducible: customer can reproduce the issue any time by booting -514 kernel... booting back to -327 kernel always resolves has not been reproduced at RedHat Steps to Reproduce: C program that does the following (full program to be attached) umask(022) open(filename,O_WRONLY|O_CREAT|O_EXCL,0777); Actual results: (on 3.10.0-514 kernels) # ./create_file # stat -c%a dummy.sh 0666 Expected results: (seen with 3.10.0-327 kernels) # ./create_file # stat -c%a dummy.sh 0755 Additional info: The customer reports that the issue occurs about 29 times out of 30, for example: >./check.sh PERM:666 PERM:666 PERM:666 ... PERM:666 PERM:666 PERM:666 PERM:755 PERM:666 PERM:666 PERM:666
Created attachment 1243730 [details] Packet capture from -327 (working) kernel
Created attachment 1243731 [details] Packet capture from -514 kernel
Created attachment 1243732 [details] nfsdebug from -327 kernel
Created attachment 1243733 [details] nfsdebug from -514 kernel
Comparison of the packet captures provided to Red Hat: -327 kernel: Frame 6: Remote Procedure Call, Type:Call PUTFH,OPEN,GETFH,GETATTR GETATTR (Mode, NumLinks, Owner, Owner_Group, RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_FileId) Frame 7: Remote Procedure Call, Type:Reply PUTFH,OPEN,GETFH,GETATTR GETATTR (Mode, NumLinks, Owner, Owner_Group, RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_FileId) fattr4_mode: 0666 Frame 8: Remote Procedure Call, Type:Call PUTFH,SETATTR,GETATTR SETATTR (Mode, Time_Access_Set, Time_Modify_Set) fattr4_mode: 0755 GETATTR (Mode, NumLinks, Owner, Owner_Group, RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_FileId) Frame 9: Remote Procedure Call, Type:Reply PUTFH,SETATTR,GETATTR SETATTR (Mode, Time_Access_Set, Time_Modify_Set) GETATTR (Mode, NumLinks, Owner, Owner_Group, RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_FileId) fattr4_mode: 0755 -514 kernel: Frame 15: Remote Procedure Call, Type:Call PUTFH,OPEN,GETFH,GETATTR GETATTR (Mode, NumLinks, Owner, Owner_Group, RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_FileId) Frame 16: Remote Procedure Call, Type:Reply PUTFH,OPEN,GETFH,GETATTR GETATTR (Mode, NumLinks, Owner, Owner_Group, RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_FileId) fattr4_mode: 0666 Frame 17: Remote Procedure Call, Type:Call PUTFH,SETATTR,GETATTR SETATTR (Time_Access_Set, Time_Modify_Set) GETATTR (Mode, NumLinks, Owner, Owner_Group, RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_FileId) Frame 18: Remote Procedure Call, Type:Reply XID:0xdfe404f5 SETATTR (Time_Access_Set, Time_Modify_Set) GETATTR (Mode, NumLinks, Owner, Owner_Group, RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_FileId) fattr4_mode: 0666 (note the difference in the third frame of each sequence, where -327 calls SETATTR(Mode), but -514 does SETATTR without Mode)
I suggested that the following commit, which is present in RHEL 7.3, but not in 7.2 might be related: commit 9b9d490bf065faf41705dd8c5f63f2d5c35b2ae8 nfs: Send attributes in OPEN request for NFS4_CREATE_EXCLUSIVE4_1 Rinku provided the customer a test -514 kernel with that commit reverted, and the customer confirmed that the file permissions worked as expected with this test kernel.
commit 9b9d490bf065faf41705dd8c5f63f2d5c35b2ae8 nfs: Send attributes in OPEN request for NFS4_CREATE_EXCLUSIVE4_1 was meant to fix the client so that it wouldn't send the mode in a SETATTR after already successfully setting the mode with EXCLUSIVE4_1, however it is also changing this behavior for EXCLUSIVE4, which is why we see this problem on nfsv4.0 if a server decides to return the mode in the OPEN response attribute mask. Probably we'll need something like: diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index ecc151697fd4..d6f931037a8b 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -2700,7 +2700,9 @@ static inline void nfs4_exclusive_attrset(struct nfs4_opendata *opendata, sattr->ia_valid |= ATTR_MTIME; /* Except MODE, it seems harmless of setting twice. */ - if ((attrset[1] & FATTR4_WORD1_MODE)) + if (opendata->o_arg.createmode & + (NFS4_CREATE_UNCHECKED | NFS4_CREATE_EXCLUSIVE4_1) && + attrset[1] & FATTR4_WORD1_MODE) sattr->ia_valid &= ~ATTR_MODE; if (attrset[2] & FATTR4_WORD2_SECURITY_LABEL) I'll send that upstream and see what sticks.
that diff in commment 16 is untested, btw, and wouldn't work anyway. The createmode is not a bitfield.
Posted upstream: http://marc.info/?l=linux-nfs&m=148527567624411&w=2
Patch(es) committed on kernel repository and an interim kernel build is undergoing testing
Patch(es) available on kernel-3.10.0-616.el7
Moved to VERIFIED according to Comment 40, will keep an eye on this phenomenon and include related test cases in next regression tests.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:1842