NFSv4: Revalidate uid/gid after open (Closes: #659111)

svn path=/dists/sid/linux-2.6/; revision=18991

debian/changelog

@@ -7,6 +7,7 @@ linux-2.6 (3.2.17-1) UNRELEASED; urgency=low
   * aufs: Enable AUFS_EXPORT
   * ext4: Report max_batch_time option correctly (Closes: #654206)
   * [i386/rt-686-pae] Enable HIGHMEM64G as intended for this configuration
+  * NFSv4: Revalidate uid/gid after open (Closes: #659111)
 
   [ Bastian Blank ]
   * [s390] Enable IUCV special message support. (closes: #671238)

debian/patches/bugfix/all/nfsv4-revalidate-uid-gid-after-open.patch

@@ -0,0 +1,74 @@
+From stable-owner@vger.kernel.org Fri May 11 10:20:33 2012
+Date: Fri, 11 May 2012 04:20:20 -0500
+From: Jonathan Nieder <jrnieder@gmail.com>
+Subject: [PATCH] NFSv4: Revalidate uid/gid after open
+
+This is a shorter (and more appropriate for stable kernels) analog to
+the following upstream commit:
+
+commit 6926afd1925a54a13684ebe05987868890665e2b
+Author: Trond Myklebust <Trond.Myklebust@netapp.com>
+Date:   Sat Jan 7 13:22:46 2012 -0500
+
+    NFSv4: Save the owner/group name string when doing open
+
+    ...so that we can do the uid/gid mapping outside the asynchronous RPC
+    context.
+    This fixes a bug in the current NFSv4 atomic open code where the client
+    isn't able to determine what the true uid/gid fields of the file are,
+    (because the asynchronous nature of the OPEN call denies it the ability
+    to do an upcall) and so fills them with default values, marking the
+    inode as needing revalidation.
+    Unfortunately, in some cases, the VFS will do some additional sanity
+    checks on the file, and may override the server's decision to allow
+    the open because it sees the wrong owner/group fields.
+
+    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
+
+Without this patch, logging into two different machines with home
+directories mounted over NFS4 and then running "vim" and typing ":q"
+in each reliably produces the following error on the second machine:
+
+	E137: Viminfo file is not writable: /users/system/rtheys/.viminfo
+
+This regression was introduced by 80e52aced138 ("NFSv4: Don't do
+idmapper upcalls for asynchronous RPC calls", merged during the 2.6.32
+cycle) --- after the OPEN call, .viminfo has the default values for
+st_uid and st_gid (0xfffffffe) cached because we do not want to let
+rpciod wait for an idmapper upcall to fill them in.
+
+The fix used in mainline is to save the owner and group as strings and
+perform the upcall in _nfs4_proc_open outside the rpciod context,
+which takes about 600 lines.  For stable, we can do something similar
+with a one-liner: make open check for the stale fields and make a
+(synchronous) GETATTR call to fill them when needed.
+
+Trond dictated the patch, I typed it in, and Rik tested it.
+
+Addresses http://bugs.debian.org/659111 and
+          https://bugzilla.redhat.com/789298
+
+Reported-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
+Explained-by: David Flyn <davidf@rd.bbc.co.uk>
+Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
+Tested-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+---
+ fs/nfs/nfs4proc.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
+index 3d6730213f9d..30f6548f2b99 100644
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -1771,6 +1771,7 @@ static int _nfs4_do_open(struct inode *dir, struct path *path, fmode_t fmode, in
+ 			nfs_setattr_update_inode(state->inode, sattr);
+ 		nfs_post_op_update_inode(state->inode, opendata->o_res.f_attr);
+ 	}
++	nfs_revalidate_inode(server, state->inode);
+ 	nfs4_opendata_put(opendata);
+ 	nfs4_put_state_owner(sp);
+ 	*res = state;
+-- 
+1.7.10.1
+

debian/patches/series/base

@@ -192,3 +192,4 @@
 
 + bugfix/all/ext4-Report-max_batch_time-option-correctly.patch
 + bugfix/all/brcm80211-smac-pass-missing-argument-to-brcms_b_mute.patch
++ bugfix/all/nfsv4-revalidate-uid-gid-after-open.patch