NFSv4.1 credential choice for the CLOSE operation

Commit Message

NeilBrown March 31, 2016, 2:44 a.m. UTC

In NFSv4.1 the client can request, in the EXCHANGE_ID operation,
permission to use machine credentials to validate a CLOSE operation.
When the server gives that permission, it does *not* include implicit
permission to use the machine credentials for the PUTFH operation which
must precede CLOSE in the same request.

At least, I cannot see that RFC5661 gives that implicit permission and a
customer has a server that doesn't give that permission.

So I conclude that it is only safe to use the machine credentials if
NFS_SP4_MACH_CRED_CLEANUP is set *and* the security tuple for the
machine credential is a tuple which is permitted for the file handle.

So I came up with the following patch which I suspect is very wrong but
at least shows where I am looking.  And compiles :-)

Details of the problem situation is that even though kerberos is
configured and usable, the NFS client is mounting with sec=sys and the
server is exporting with a similar setting.
So kerberos is used to provide a machine credential and to validate
state management, but AUTH_SYS is used for all file accesses.

In this context here is no *need* to use the machine credential to
validate CLOSE because AUTH_SYS credentials never expire.  But the linux
NFS client does anyway, and the server rejects the PUT_FH because it
wasn't authenticated with AUTH_SYS.

Can anyone suggest what a better fix would be - or explain to me how I
have misread the RFC?

Thanks a lot,
NeilBrown

Comments

J. Bruce Fields March 31, 2016, 5:54 p.m. UTC | #1

On Thu, Mar 31, 2016 at 01:44:32PM +1100, NeilBrown wrote:
> In NFSv4.1 the client can request, in the EXCHANGE_ID operation,
> permission to use machine credentials to validate a CLOSE operation.
> When the server gives that permission, it does *not* include implicit
> permission to use the machine credentials for the PUTFH operation which
> must precede CLOSE in the same request.
> 
> At least, I cannot see that RFC5661 gives that implicit permission and a
> customer has a server that doesn't give that permission.

Ugh.  Yeah, the first section I thought to check was

	http://tools.ietf.org/html/rfc5661#section-2.6.3

which allows deferring checks until an operation following the putfh in
some cases, but not in this case.  I haven't reviewed the state
protection sections.

It sounds like a protocol bug to me.

I wonder why CLOSE takes a filehandle at all.  The server can look up
the stateid without the filehandle.  And permissions to close should be
deterined by who "owns" that open, not by file permissions.

--b.

> 
> So I conclude that it is only safe to use the machine credentials if
> NFS_SP4_MACH_CRED_CLEANUP is set *and* the security tuple for the
> machine credential is a tuple which is permitted for the file handle.
> 
> So I came up with the following patch which I suspect is very wrong but
> at least shows where I am looking.  And compiles :-)
> 
> Details of the problem situation is that even though kerberos is
> configured and usable, the NFS client is mounting with sec=sys and the
> server is exporting with a similar setting.
> So kerberos is used to provide a machine credential and to validate
> state management, but AUTH_SYS is used for all file accesses.
> 
> In this context here is no *need* to use the machine credential to
> validate CLOSE because AUTH_SYS credentials never expire.  But the linux
> NFS client does anyway, and the server rejects the PUT_FH because it
> wasn't authenticated with AUTH_SYS.
> 
> Can anyone suggest what a better fix would be - or explain to me how I
> have misread the RFC?
> 
> Thanks a lot,
> NeilBrown
> 
> 
> diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
> index 4afdee420d25..b1694890feb1 100644
> --- a/fs/nfs/nfs4_fs.h
> +++ b/fs/nfs/nfs4_fs.h
> @@ -297,7 +297,9 @@ _nfs4_state_protect(struct nfs_client *clp, unsigned long sp4_mode,
>  	struct rpc_cred *newcred = NULL;
>  	rpc_authflavor_t flavor;
>  
> -	if (test_bit(sp4_mode, &clp->cl_sp4_flags)) {
> +	if (test_bit(sp4_mode, &clp->cl_sp4_flags) &&
> +	    (*clntp)->cl_auth->au_flavor
> +	    == clp->cl_rpcclient->cl_auth->au_flavor) {
>  		spin_lock(&clp->cl_lock);
>  		if (clp->cl_machine_cred != NULL)
>  			/* don't call get_rpccred on the machine cred -


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
index 4afdee420d25..b1694890feb1 100644
--- a/fs/nfs/nfs4_fs.h
+++ b/fs/nfs/nfs4_fs.h
@@ -297,7 +297,9 @@  _nfs4_state_protect(struct nfs_client *clp, unsigned long sp4_mode,
 	struct rpc_cred *newcred = NULL;
 	rpc_authflavor_t flavor;
 
-	if (test_bit(sp4_mode, &clp->cl_sp4_flags)) {
+	if (test_bit(sp4_mode, &clp->cl_sp4_flags) &&
+	    (*clntp)->cl_auth->au_flavor
+	    == clp->cl_rpcclient->cl_auth->au_flavor) {
 		spin_lock(&clp->cl_lock);
 		if (clp->cl_machine_cred != NULL)
 			/* don't call get_rpccred on the machine cred -