From: NeilBrown <neilb@suse.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>,
Anna Schumaker <anna.schumaker@netapp.com>
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH 8/8] NFSv4.1: don't use machine credentials for CLOSE when using 'sec=sys'
Date: Fri, 18 Aug 2017 17:12:52 +1000 [thread overview]
Message-ID: <150304037211.30218.1236272488580678069.stgit@noble> (raw)
In-Reply-To: <150304014011.30218.1636255532744321171.stgit@noble>
An NFSv4.1 client might close a file after the user who opened it has
logged off. In this case the user's credentials may no longer be
valid, if they are e.g. kerberos credentials that have expired.
NFSv4.1 has a mechanism to allow the client to use machine credentials
to close a file. However due to a short-coming in the RFC, a CLOSE
with those credentials may not be possible if the file in question
isn't exported to the same security flavor - the required PUTFH must
be rejected when this is the case.
Specifically if a server and client support kerberos in general and
have used it to form a machine credential, but the file is only
exported to "sec=sys", a PUTFH with the machine credentials will fail,
so CLOSE is not possible.
As RPC_AUTH_UNIX (used by sec=sys) credentials can never expire, there
is no value in using the machine credential in place of them.
So in that case, just use the users credentials for CLOSE etc, as you would
in NFSv4.0
Signed-off-by: Neil Brown <neilb@suse.com>
Signed-off-by: NeilBrown <neilb@suse.com>
---
fs/nfs/nfs4_fs.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
index 40bd05f05e74..ac4f10b7f6c1 100644
--- a/fs/nfs/nfs4_fs.h
+++ b/fs/nfs/nfs4_fs.h
@@ -303,6 +303,17 @@ _nfs4_state_protect(struct nfs_client *clp, unsigned long sp4_mode,
struct rpc_cred *newcred = NULL;
rpc_authflavor_t flavor;
+ if (sp4_mode == NFS_SP4_MACH_CRED_CLEANUP ||
+ sp4_mode == NFS_SP4_MACH_CRED_PNFS_CLEANUP) {
+ /* Using machine creds for cleanup operations
+ * is only relevent if the client credentials
+ * might expire. So don't bother for
+ * RPC_AUTH_UNIX. If file was only exported to
+ * sec=sys, the PUTFH would fail anyway.
+ */
+ if ((*clntp)->cl_auth->au_flavor == RPC_AUTH_UNIX)
+ return false;
+ }
if (test_bit(sp4_mode, &clp->cl_sp4_flags)) {
spin_lock(&clp->cl_lock);
if (clp->cl_machine_cred != NULL)
prev parent reply other threads:[~2017-08-18 7:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-18 7:12 [PATCH 0/8] Assorted NFS patches NeilBrown
2017-08-18 7:12 ` [PATCH 1/8] SUNRPC: ECONNREFUSED should cause a rebind NeilBrown
2017-08-18 14:40 ` Chuck Lever
2017-08-18 7:12 ` [PATCH 4/8] NFS: flush out dirty data on file fput() NeilBrown
2017-08-18 19:15 ` Trond Myklebust
2017-08-19 1:02 ` NeilBrown
2017-08-19 1:27 ` Trond Myklebust
2017-08-21 1:35 ` NeilBrown
2017-08-23 11:12 ` Jeff Layton
2017-08-18 7:12 ` [PATCH 3/8] NFS: don't expect errors from mempool_alloc() NeilBrown
2017-08-18 7:12 ` [PATCH 2/8] NFSv4: don't let hanging mounts block other mounts NeilBrown
2017-08-18 19:05 ` Trond Myklebust
2017-08-19 0:50 ` NeilBrown
2017-08-18 7:12 ` [PATCH 6/8] NFS: flush data when locking a file to ensure cache coherence for mmap NeilBrown
2017-08-18 7:12 ` [PATCH 7/8] NFS: remove error handling for callers of rpc_new_task() NeilBrown
2017-08-18 7:12 ` [PATCH 5/8] SUNRPC: remove some dead code NeilBrown
2017-08-18 7:12 ` NeilBrown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=150304037211.30218.1236272488580678069.stgit@noble \
--to=neilb@suse.com \
--cc=anna.schumaker@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox