On Wed, May 14, 2025 at 2:51 PM Martin Wege <martin.l.wege@xxxxxxxxx> wrote: > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@xxxxxxxxxxx. > > > 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. I will note that it is possible to configure a client to use SP4_NONE and do Kerberos mounts without needing a Kerberos ticket. This avoids the hassle of creating keytab entries for clients. Once you do that, all you really need is a KDC (either MIT or Heimdal can be set up easily) and the creation of a service principal for the server and putting it in a keytab on the server. (This really is not hard to do. I won't comment on what Linux distros provide, since I have no expertise.) > > > 2. TLS: Wanna make NFS even slower? Then use NFS with TLS. > > NFS filesystem over TLS support then feels like working with molasses. This is not my limited experience. I have two old Dell laptops and they easily do NFS over TLS at wire speed for their 1Gbps net ports. (They do use about 30% of a CPU for each active mount's TCP connection.) For faster (10Gbps-->) net connections, I wouldn't be surprised that you will see a performance hit without offload hardware, but I'm not sure I would call it "molasses". There is offload hardware out there, but I have no access to such. I will agree that NFS over TLS does not make sense for a well controlled LAN, but the university example may not be a well controlled LAN, except maybe within a server machine room. > > 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. Actually, I could have said it was a FreeBSD only solution at one point in time. Now, both Linux and FreeBSD clients do it. And, although I'd like to say otherwise, there are not a lot of other current clients out there. (Yes, I know you are involved in the resurrected CITI Windows client, which is good to see.) I'd like to see the Windows client learn how to do NFS over TLS, since a Windows laptop would be an ideal example of a client that could use NFS over TLS. (With it, it can access a NFSv4 server from pretty well anywhere. It is also possible to put a username in an X.509 cert. on the client so that it performs all RPCs as that user and avoids any need for Kerberos or messing with passwd/group entries. When this is done it can stick any old uid/gid in the RPC header, because they are ignored anyhow.) Would I like to see Apple do this? Yes. Do I expect MacOS to get this any time soon. Nope, since they have never even upgraded their client to 4.1. As for the VMware client, I doubt there is much use for NFS over TLS in it. What other clients are there out there? (Hummingbird's, now called OpenText's NFSv4.0 client. I was surprised to see it was still possible to buy it. And it probably can be put in the same category as the MacOS one.) As for the merits of reserved port #s.. I'm staying out of that one. I made the mistake of going down that rabbit hole some years ago. (I'll admit there are certain situations where a reserved port# restriction is useful. A system where root is trusted, but the users are not, could be one.) rick > 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 >
