RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
Embargoed:

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
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1315390 1 None None None 2021-06-10 11:11:30 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.