On Tue, 4 Dec 2018 at 20:53, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Tue, Dec 04, 2018 at 02:39:12PM -0500, J. Bruce Fields wrote: > > 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@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. > > > > 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. > > Hm, OK I'll be honest I'm reluctant to devote a lot of time to debugging > this unusual combination (reiserfs with posix acl support configured > out), but on a quick skim it looks like reiser *might* depend on > reiserfs_inherit_default_acl() to apply the umask, but in your case > that's probably configured to be a dummy function that does nothing. > And in that case the vfs should take responsibility for applying the > umask, but that depends on SB_POSIXACL being unset on the superblock--I > wonder if that could be set incorrectly? I wonder if ext4 shows the same behavior with POSIX ACLs configured out? Andreas
