Bug 1415780 - File permissions are not getting set as expected on nfs v4.0 mount
Summary: File permissions are not getting set as expected on nfs v4.0 mount
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.3
Hardware: All
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Benjamin Coddington
QA Contact: ChunYu Wang
URL:
Whiteboard:
Depends On:
Blocks: 1437967
TreeView+ depends on / blocked
 
Reported: 2017-01-23 17:15 UTC by Frank Sorenson
Modified: 2020-09-10 10:08 UTC (History)
14 users (show)

Fixed In Version: kernel-3.10.0-616.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1437967 (view as bug list)
Environment:
Last Closed: 2017-08-02 05:10:53 UTC
Target Upstream Version:


Attachments (Terms of Use)
Customer's reproducer program (276 bytes, text/x-csrc)
2017-01-23 17:15 UTC, Frank Sorenson
no flags Details
Packet capture from -327 (working) kernel (3.67 KB, application/octet-stream)
2017-01-23 17:17 UTC, Frank Sorenson
no flags Details
Packet capture from -514 kernel (13.58 KB, application/octet-stream)
2017-01-23 17:18 UTC, Frank Sorenson
no flags Details
nfsdebug from -327 kernel (26.57 KB, text/plain)
2017-01-23 17:19 UTC, Frank Sorenson
no flags Details
nfsdebug from -514 kernel (23.44 KB, text/plain)
2017-01-23 17:19 UTC, Frank Sorenson
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1315390 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Knowledge Base (Solution) 2886411 0 None None None 2017-03-07 14:57:33 UTC
Red Hat Product Errata RHSA-2017:1842 0 normal SHIPPED_LIVE Important: kernel security, bug fix, and enhancement update 2017-08-01 18:22:09 UTC

Internal Links: 1315390

Description Frank Sorenson 2017-01-23 17:15:51 UTC
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

Comment 1 Frank Sorenson 2017-01-23 17:17:20 UTC
Created attachment 1243730 [details]
Packet capture from -327 (working) kernel

Comment 2 Frank Sorenson 2017-01-23 17:18:14 UTC
Created attachment 1243731 [details]
Packet capture from -514 kernel

Comment 3 Frank Sorenson 2017-01-23 17:19:21 UTC
Created attachment 1243732 [details]
nfsdebug from -327 kernel

Comment 4 Frank Sorenson 2017-01-23 17:19:56 UTC
Created attachment 1243733 [details]
nfsdebug from -514 kernel

Comment 8 Frank Sorenson 2017-01-23 17:50:21 UTC
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)

Comment 9 Frank Sorenson 2017-01-23 18:09:10 UTC
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.

Comment 16 Benjamin Coddington 2017-01-24 15:38:41 UTC
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.

Comment 17 Benjamin Coddington 2017-01-24 15:48:40 UTC
that diff in commment 16 is untested, btw, and wouldn't work anyway.  The createmode is not a bitfield.

Comment 18 Benjamin Coddington 2017-01-24 16:39:20 UTC
Posted upstream:
http://marc.info/?l=linux-nfs&m=148527567624411&w=2

Comment 36 Rafael Aquini 2017-03-18 00:53:13 UTC
Patch(es) committed on kernel repository and an interim kernel build is undergoing testing

Comment 38 Rafael Aquini 2017-03-20 20:44:10 UTC
Patch(es) available on kernel-3.10.0-616.el7

Comment 42 ChunYu Wang 2017-03-22 10:24:22 UTC
Moved to VERIFIED according to Comment 40, will keep an eye on this phenomenon and include related test cases in next regression tests.

Comment 55 errata-xmlrpc 2017-08-02 05:10:53 UTC
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


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