Patch "NFSv4: Don't perform cached access checks before we've OPENed the file" has been added to the 4.4-stable tree

PATCH [email protected] 1 participant 1 message Jun 12, 2017

Subsystems (2)

Stable branch NFS client

lore

Share & tools

lore

[email protected]

author maintainer Applied

2017-06-12 12:50 UTC #0 lore raw

This is a note to let you know that I've just added the patch titled

NFSv4: Don't perform cached access checks before we've OPENed the file

to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
nfsv4-don-t-perform-cached-access-checks-before-we-ve-opened-the-file.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From 762674f86d0328d5dc923c966e209e1ee59663f2 Mon Sep 17 00:00:00 2001

From: Trond Myklebust <[email protected]>
Date: Sat, 26 Dec 2015 21:54:58 -0500
Subject: NFSv4: Don't perform cached access checks before we've OPENed the file

From: Trond Myklebust <[email protected]>

commit 762674f86d0328d5dc923c966e209e1ee59663f2 upstream.

Donald Buczek reports that a nfs4 client incorrectly denies execute access based on outdated file mode (missing 'x' bit). After the mode on the server is 'fixed' (chmod +x) further execution attempts continue to fail, because the nfs ACCESS call updates the access parameter but not the mode parameter or the mode in the inode.

The root cause is ultimately that the VFS is calling may_open() before the NFS client has a chance to OPEN the file and hence revalidate the access and attribute caches.

Al Viro suggests:

Quoted 11 lines

Quoted 7 lines
Quoted 2 lines
Make nfs_permission() relax the checks when it sees MAY_OPEN, if you know that things will be caught by server anyway?
That can work as long as we're guaranteed that everything that calls inode_permission() with MAY_OPEN on a regular file will also follow up with a vfs_open() or dentry_open() on success. Is this always the case?
1) in do_tmpfile(), followed by do_dentry_open() (not reachable by NFS since it doesn't have ->tmpfile() instance anyway)

Quoted 6 lines

2) in atomic_open(), after the call of ->atomic_open() has succeeded.
3) in do_last(), followed on success by vfs_open()
That's all. All calls of inode_permission() that get MAY_OPEN come from may_open(), and there's no other callers of that puppy.

Reported-by Donald Buczek <[email protected]>

Link https://bugzilla.kernel.org/show_bug.cgi?id=109771

Link http://lkml.kernel.org/r/[email protected] open here

Cc Al Viro <[email protected]>

Signed-off-by Trond Myklebust <[email protected]>

Signed-off-by Paul Menzel <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/nfs/dir.c |    3 +++
 1 file changed, 3 insertions(+)

fs/nfs/dir.c +3 -0

@@ -2452,6 +2452,9 @@ int nfs_permission(struct inode *inode,
 		case S_IFLNK:
 			goto out;
 		case S_IFREG:
+			if ((mask & MAY_OPEN) &&
+			   nfs_server_capable(inode, NFS_CAP_ATOMIC_OPEN))
+				return 0;
 			break;
 		case S_IFDIR:
 			/*

Patches currently in stable-queue which might be from [email protected] are

queue-4.4/nfsd-fix-up-the-supattr_exclcreat-attributes.patch queue-4.4/nfsv4-don-t-perform-cached-access-checks-before-we-ve-opened-the-file.patch queue-4.4/nfs-ensure-we-revalidate-attributes-before-using-execute_ok.patch