Bug 30862

Summary:	Incorrect permissions on NFSv4 mounts, but OK after explicit stat
Product:	File System	Reporter:	rik.theys
Component:	NFS	Assignee:	Trond Myklebust (trondmy)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	alan, rik.theys
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.32 to 2.6.38-rc6	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	Network dump

Description rik.theys 2011-03-10 11:04:53 UTC

Hi,

I've already filed this bug with red hat and debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617508
https://bugzilla.redhat.com/show_bug.cgi?id=683372

I tried this with kernels 2.6.32 (both the debian ones and the rhel ones). I also have this on RHEL 5.5 and 5.6. Also verified it with 2.6.38-rc6 from Debian.

Say you have a directory A with root:root as the owner and 755 as permissions. In this directory you have a file with owner user:user with permissions 600.

If this directory is mounted over NFSv4 and user tries to append to the file before a stat of the file has happened, it will receive a permission denied error. Repeating the append repeats the error. Only after running an explicit stat on the file, the append works.

It seems the NFS4 client assumes the same permissions as the directory for the file you're trying to append and therefore refuses the append. When the permissions are requested by the client it works. After a while (a few minutes), the client seems to have forgotten about the correct permissions and the error comes back.

I can provide detailed instructions on how to reproduce this if needed. I also have a disk image for a Debian squeeze VM on which I reproduce this if needed.

I will rerun my tests and provide a tcpdump as well.

Regards,

Rik

Comment 1 rik.theys 2011-03-10 12:25:37 UTC

Created attachment 50582 [details]
Network dump

I used one system running 2.6.38-rc6 as both the server and client. The client mounted the nfs4 share over the loopback interface.

Sequence of commands:
 - start of tcpdump
 - mount of filesystem
 - ping to localhost so i can see it in the dump
 - run my trigger script (returns error)
 - ping to localhost
 - run my trigger script again a few times (always returns error)
 - ping to localhost
 - stat the file
 - ping to localhost
 - run my trigger script, no error

Comment 2 rik.theys 2011-03-10 12:27:34 UTC

My trigger script is a ksh script:

#! /bin/ksh
printf "hello world" >> /mnt/b/datafile

I mounted the nfs4 filesystem under /mnt and b is a directory on the mount. The permissions on b are 755 root:root, The permissions on the datafile are 0600 user:user.

Comment 3 rik.theys 2011-03-11 07:57:44 UTC

Also verified it on Debian Etch r0 2.6.18 kernel. It has the same problem.

Comment 4 rik.theys 2011-04-14 12:01:51 UTC

Red Hat has debugged this problem and have posted a patch in the bugzilla entry:

https://bugzilla.redhat.com/show_bug.cgi?id=683372

I recompiled the RHEL6 kernel with the patch applied and can confirm that it fixes this bug.

Comment 5 rik.theys 2011-04-20 12:20:00 UTC

Proposed patch on linux-nfs mailing list

http://thread.gmane.org/gmane.linux.nfs/40010