On Mon, 26 Nov 2018, Andreas Gruenbacher wrote:
On Mon, 26 Nov 2018 at 15:07, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:On Sat, Nov 24, 2018 at 08:18:40PM -0500, Byron Stanoszek wrote:I would like to report a problem with NFS v4.2: the umask seems to be getting dropped when creating files. This works as expected when connecting with a v4.1 client or any version prior.Watching the network traffic in wireshark might help determine which side is at fault.Right, a network dump (tcpdump -w) of the incorrect operation(s) would be great so that we can have a look with wireshark.
Sorry for the delay. I attached the two tcpdump files from the client side. The server is 10.0.0.2 (lnxsvr1) and the client is 10.0.0.13 (burner). In both cases, I ran: mount lnxsvr1:/test -overs=4.x /ext0 touch /ext0/blah umount /ext0 and waited ~3 seconds between each command entry.
In 4.2 the umask is sent in a separate attribute, in earlier versions the umask and open mode are combined by the client and only the result is sent.
Does "separate attribute" mean "future packet transmission", or is the file_create+change_mode operation still atomic? I'm concerned that if "root" creates an unexpected mode 666 file via the nfs client for a short period of time, that opens up an avenue for a non-root user on the server side to write things into the file before the nfs server processes the "umask" command/packet.
What filesystem type is /users/files on on lnxsvr1?
reiserfs, with XATTRs disabled: CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_REISERFS_FS_XATTR is not set Thanks, -Byron
Attachment:
nfs4_1.pcap
Description: application/vnd.tcpdump.pcap
Attachment:
nfs4_2.pcap
Description: application/vnd.tcpdump.pcap
