On Wed, May 14, 2025 at 1:55 PM NeilBrown <neil@xxxxxxxxxx> wrote: > > On Wed, 14 May 2025, Jeff Layton wrote: > Ignoring source ports makes no sense at all unless you enforce some other > authentication, like krb5 or TLS, or unless you *know* that there are no > unprivileged processes running on any client machines. I don't like to ruin that party, but this is NOT realistic. 1. Kerberos5 support is HARD to set up, and fragile because not all distributions test it on a regular basis. Config is hard, not all distributions support all kinds of encryption methods, and Redhat's crusade&maintainer mobbing to promote sssd at the expense of other solutions left users with a half broken, overcomplicated Windows Active Directory clone called sssd, which is an insane overkill for most scenarios. gssproxy is also a constant source of pain - just Google for the Debian bug reports. Short: Lack of test coverage in distros, not working from time to time, sssd and gssproxy are more of a problem than a solution. It really only makes sense for very big sites and a support contract which covers support and bug fixes for Kerberos5 in NFS+gssproxy. 2. TLS: Wanna make NFS even slower? Then use NFS with TLS. NFS filesystem over TLS support then feels like working with molasses. Exacerbated by Linux's crazy desire to only support hyper-secure post-quantum encryption method (so no fast arcfour, because that is "insecure", and everyone is expected to only work with AMD Threadripper 3995WX), lack of good threading through the TLS eye of the needle, and LACK of support in NFS clients. Interoperability is also a big problem (nay, it's ZERO interoperability), as this is basically a Linux kernel client/kernel server only solution. libtirpc doesn't support TLS, Ganesha doesn't support TLS, so yeah, this is an issue, and not a solution. Fazit: Supporting your argumentation with Kerberos5 or TLS is not gonna fly. Thanks, Martin
