Bug 1667761 - Process umask ignored when mounting NFSv4.2 share
Summary: Process umask ignored when mounting NFSv4.2 share
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-21 00:46 UTC by W. Michael Petullo
Modified: 2019-11-08 16:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
NFSv4.2 interaction packet capture (81.92 KB, text/plain)
2019-11-08 16:43 UTC, W. Michael Petullo
no flags Details

Description W. Michael Petullo 2019-01-21 00:46:24 UTC
Description of problem:
I have an NFS share which I mount from a Fedora workstation. When I mount the share using NFSv4.2, I find that the process umask is ignored when creating files and directories within the share. Files are created with 666 permissions, and directories are created with 777 permissions. Mounting the same share with NFSv4.1 rather than 4.2 works fine.

Version-Release number of selected component (if applicable):
nfs-utils-2.3.3-1.rc2.fc29.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Mount an NFSv4.2 share at /mnt
2. mkdir /mnt/foo
3. ls -ld /mnt/foo

Actual results:
Permissions are 777.

Expected results:
Permissions should be 755, due to a process umask of 0022.

Additional info:
The NFS server runs OpenWrt.

This seems related to a similar Ubuntu report:

https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736

I suspect this results from changes due to the RFC "Allowing Inheritable NFSv4 ACLs to Override the Umask:"

https://tools.ietf.org/id/draft-ietf-nfsv4-umask-03.html

Comment 1 J. Bruce Fields 2019-01-21 15:22:33 UTC
THis would be expected if there were some kind of inheritable acls set on the export, can you tell if that's the case?

What kernel (from uname -a) is the server running, and what's the exported filesystem?

To start debugging this, I'd recommend looking running wireshark to sniff traffic while running your reproducer (mount, mkdir) and compare to what's expected from the umask RFC.  Somewhere there should be a getattr from the client for the supported_attrs attribute, and the reply from the server will probably indicate support for the new mode_umask attribute.  If you find the CREATE operation that creates the new directory, you should see the client set the mode_umask attribute, with the mode part set to the open mode and the umask to the process umask.  If those values look right, then the problem is likely on the server side.

Comment 2 Ben Cotton 2019-10-31 19:50:37 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 W. Michael Petullo 2019-11-08 16:13:23 UTC
Still present in Fedora 31. 

The server is an OpenWrt build running 4.19.78 on x86_64.

See also: https://bugs.openwrt.org/index.php?do=details&task_id=2581 for more information about the client.

Comment 4 W. Michael Petullo 2019-11-08 16:43:32 UTC
Created attachment 1634077 [details]
NFSv4.2 interaction packet capture

This captures the network traffic associated with the following commands:

mount -o vers=4.2 golem.flyn.org:/home/mike /mnt
touch /mnt/foo
ls -l /mnt/foo
umount /mnt


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