SUNRPC: Consider qop when looking up pseudoflavors
authorChuck Lever <chuck.lever@oracle.com>
Sat, 16 Mar 2013 19:55:01 +0000 (15:55 -0400)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Fri, 29 Mar 2013 19:43:24 +0000 (15:43 -0400)
commit83523d083a045a2069e5f3443d2e4f810a6e6d9a
treee09dba12aaa71997d1ebe1913ddf6a3f9d5f55cb
parentf783288f0cf47f1988f5284c89e325bd22c74f91
SUNRPC: Consider qop when looking up pseudoflavors

The NFSv4 SECINFO operation returns a list of security flavors that
the server supports for a particular share.  An NFSv4 client is
supposed to pick a pseudoflavor it supports that corresponds to one
of the flavors returned by the server.

GSS flavors in this list have a GSS tuple that identify a specific
GSS pseudoflavor.

Currently our client ignores the GSS tuple's "qop" value.  A
matching pseudoflavor is chosen based only on the OID and service
value.

So far this omission has not had much effect on Linux.  The NFSv4
protocol currently supports only one qop value: GSS_C_QOP_DEFAULT,
also known as zero.

However, if an NFSv4 server happens to return something other than
zero in the qop field, our client won't notice.  This could cause
the client to behave in incorrect ways that could have security
implications.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
include/linux/sunrpc/gss_api.h
net/sunrpc/auth_gss/gss_krb5_mech.c
net/sunrpc/auth_gss/gss_mech_switch.c
net/sunrpc/auth_gss/svcauth_gss.c