Hi-
Currently the RPC client is able to dynamically load GSS security
flavor support by name or pseudoflavor number, but not by
[OID, qop, service] tuple. Such a tuple is provided by a server in
a SECINFO reply.
This means that if a server lists a tuple for, say, krb5p, in a
SECINFO reply, the client will pretend it doesn't support it if the
kernel module for krb5p is available on the system but does not
happen to be loaded at that moment.
This series implements support for loading the correct GSS module
before searching by GSS tuple. The series has seen some successful
light testing, so it's time for wider review. Suggestions about how
to test this series are welcome.
Trond, back when we discussed this change, there was also some
hand-waving about how to deal with WRONG_SEC on the pseudo-fs root.
Any thoughts or recollection about that?
I have 'But we have to worry about WRONG_SEC on the root. "Fixed in
4.1, but fucking bug in 4.0.' and then 'For NFSv4.0 root FS, we can
use a fixed array of mandated flavors, and the new "try to autoload
pseudo flavor" API'.
Somehow that's going to have to be folded into the 4.0 trunking
detection logic.
---
Chuck Lever (5):
SUNRPC: Consider qop when looking up pseudoflavors
SUNRPC: Find kernel module by OID
SUNRPC: Introduce rpcauth_lookup_gss_pseudoflavor()
SUNRPC: Define rpcsec_gss_info structure
NFS: Remove unneeded forward declaration
fs/nfs/nfs4namespace.c | 48 +++++++++++++++++------------
fs/nfs/nfs4xdr.c | 20 +++++++-----
include/linux/nfs_xdr.h | 24 +++-----------
include/linux/sunrpc/auth.h | 4 ++
include/linux/sunrpc/auth_gss.h | 6 ----
include/linux/sunrpc/gss_api.h | 25 +++++++++++++--
net/sunrpc/Kconfig | 1 +
net/sunrpc/auth.c | 31 +++++++++++++++++++
net/sunrpc/auth_gss/auth_gss.c | 1 +
net/sunrpc/auth_gss/gss_krb5_mech.c | 4 ++
net/sunrpc/auth_gss/gss_mech_switch.c | 55 ++++++++++++++++++++++++++++++---
11 files changed, 158 insertions(+), 61 deletions(-)
--
Chuck Lever
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
