In order for an NFS client with support for the newer encryption types (AES with SHA2 and Camellia) in its RPCSEC GSS kernel code to connect to an NFS server without support for those encryption types in its RPCSEC GSS kernel code, it is sometimes necessary for configuration changes on the NFS server... particularly if the NFS server's userspace krb5 code does have support for the newer encryption types and/or the NFS server's keytab has "nfs" keys using the newer encryption types. Rather than rehashing the whole discussion here in the cover letter, see the description in the first patch for the gory details. These patches make it easier for a "newer" NFS client to work with an "older" NFS server. The first patch adds support for an "allowed-enctypes" option in nfs.conf, allowing the the client to restrict the permitted encryption types to a subset of what is otherwise supported in its krb5 environment so that it doesn't use an encryption type that the NFS server doesn't support when negotiating a GSS context. The second patch builds on this by adding an automatic backoff feature, where if the NFS client fails to negotiate a GSS context with the NFS server using the newer encryption types, it will try again without using the newer encryption types. With these patches in place on the NFS client, the "newer" NFS client will work with an "older" NFS server without requiring any configuration changes. Scott Mayhew (2): gssd: add support for an "allowed-enctypes" option in nfs.conf gssd: add a "backoff" feature to limit_krb5_enctypes() nfs.conf | 1 + utils/gssd/gssd.c | 6 ++ utils/gssd/gssd.man | 9 +++ utils/gssd/gssd_proc.c | 15 ++++- utils/gssd/krb5_util.c | 135 ++++++++++++++++++++++++++++++++++++++--- utils/gssd/krb5_util.h | 3 +- 6 files changed, 159 insertions(+), 10 deletions(-) -- 2.43.0
