mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-08-25 02:09:42 +00:00
NFS: Use static list of security flavors during root FH lookup recovery
If the Linux NFS client receives an NFS4ERR_WRONGSEC error while trying to look up an NFS server's root file handle, it retries the lookup operation with various security flavors to see what flavor the NFS server will accept for pseudo-fs access. The list of flavors the client uses during retry consists only of flavors that are currently registered in the kernel RPC client. This list may not include any GSS pseudoflavors if auth_rpcgss.ko has not yet been loaded. Let's instead use a static list of security flavors that the NFS standard requires the server to implement (RFC 3530bis, section 3.2.1). The RPC client should now be able to load support for these dynamically; if not, they are skipped. Recovery behavior here is prescribed by RFC 3530bis, section 15.33.5: > For LOOKUPP, PUTROOTFH and PUTPUBFH, the client will be unable to > use the SECINFO operation since SECINFO requires a current > filehandle and none exist for these two [sic] operations. Therefore, > the client must iterate through the security triples available at > the client and reattempt the PUTROOTFH or PUTPUBFH operation. In > the unfortunate event none of the MANDATORY security triples are > supported by the client and server, the client SHOULD try using > others that support integrity. Failing that, the client can try > using AUTH_NONE, but because such forms lack integrity checks, > this puts the client at risk. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Cc: Bryan Schumaker <bjschuma@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
This commit is contained in:
parent
83ca7f5ab3
commit
9a744ba398
1 changed files with 20 additions and 12 deletions
|
@ -2514,27 +2514,35 @@ static int nfs4_lookup_root_sec(struct nfs_server *server, struct nfs_fh *fhandl
|
|||
return ret;
|
||||
}
|
||||
|
||||
/*
|
||||
* Retry pseudoroot lookup with various security flavors. We do this when:
|
||||
*
|
||||
* NFSv4.0: the PUTROOTFH operation returns NFS4ERR_WRONGSEC
|
||||
* NFSv4.1: the server does not support the SECINFO_NO_NAME operation
|
||||
*
|
||||
* Returns zero on success, or a negative NFS4ERR value, or a
|
||||
* negative errno value.
|
||||
*/
|
||||
static int nfs4_find_root_sec(struct nfs_server *server, struct nfs_fh *fhandle,
|
||||
struct nfs_fsinfo *info)
|
||||
{
|
||||
int i, len, status = 0;
|
||||
rpc_authflavor_t flav_array[NFS_MAX_SECFLAVORS];
|
||||
|
||||
len = rpcauth_list_flavors(flav_array, ARRAY_SIZE(flav_array));
|
||||
if (len < 0)
|
||||
return len;
|
||||
|
||||
for (i = 0; i < len; i++) {
|
||||
/* AUTH_UNIX is the default flavor if none was specified,
|
||||
* thus has already been tried. */
|
||||
if (flav_array[i] == RPC_AUTH_UNIX)
|
||||
continue;
|
||||
/* Per 3530bis 15.33.5 */
|
||||
static const rpc_authflavor_t flav_array[] = {
|
||||
RPC_AUTH_GSS_KRB5P,
|
||||
RPC_AUTH_GSS_KRB5I,
|
||||
RPC_AUTH_GSS_KRB5,
|
||||
RPC_AUTH_NULL,
|
||||
};
|
||||
int status = -EPERM;
|
||||
size_t i;
|
||||
|
||||
for (i = 0; i < ARRAY_SIZE(flav_array); i++) {
|
||||
status = nfs4_lookup_root_sec(server, fhandle, info, flav_array[i]);
|
||||
if (status == -NFS4ERR_WRONGSEC || status == -EACCES)
|
||||
continue;
|
||||
break;
|
||||
}
|
||||
|
||||
/*
|
||||
* -EACCESS could mean that the user doesn't have correct permissions
|
||||
* to access the mount. It could also mean that we tried to mount
|
||||
|
|
Loading…
Reference in a new issue