| Message ID | 20240228222253.1080880-1-smayhew@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | gssd: improve interoperability with NFS servers that don't have support for the newest encryption types | expand |
Re-adding the list. On Mon, 04 Mar 2024, Scott Mayhew wrote: > On Mon, 04 Mar 2024, Olga Kornievskaia wrote: > > > On Wed, Feb 28, 2024 at 5:23 PM Scott Mayhew <smayhew@redhat.com> wrote: > > > > > > 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. > > > > I'm stuck on "the NFs server's keytab has nfs keys" with newer > > encryption types. That sounds like a misconfigured server. The > > administrator shouldn't have issued a keytab knowingly that those > > encryption types are not supported. > > I think it's probably pretty common for administrators to omit the -e > option when they use 'kadmin ktadd' or 'ipa-getkeytab', so they get keys > for whatever's enabled in their krb5 configuration. > > But It turns out that part is not even necessary for the problem to occur. > As long as the krb5 configuration has those encryption types enabled, the > problem can occur. See the thread posted by Orion Poplawski on 2/29: > https://lore.kernel.org/linux-nfs/181e6547-a0ec-4c02-844b-bf1eda464acd@nwra.com/T/#t > > -Scott > > > > > 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 > > > > > > > >