Re: NFS v4.2 umask getting dropped

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Nov 30, 2018 at 10:13:59PM -0500, Byron Stanoszek wrote:
> On Mon, 26 Nov 2018, Andreas Gruenbacher wrote:
> 
> >On Mon, 26 Nov 2018 at 15:07, J. Bruce Fields <bfields@fieldses.org> 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.

Thanks!

I looked at nfs4_2.pcap.  You can see the OPEN that creates the file in
frame 56.  If expand OPEN->Open Type you'll see the only attribute it's
setting htere is mode_umask, with mode 0666 and umask 022.

There's a GETATTR later in the compound which queries attributes
including the mode.  The reply, in frame frame 57, gives 0666 for the
mode.

So, that's a server bug: for some reason the server isn't applying the
umask it was given.

> >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.

So the mode_umask is being sent as part of the OPEN, and knfsd is
supposed to apply the mode and umask atomically.

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

OK, seems unlikely to be a reiserfs bug, but that's also something
that's probably doesn't get a lot of testing.

--b.