The history of our custom NFS mount authorization system (or some of it)

July 3, 2018

I recently wrote an entry about the shifting goals of our custom NFS mount authorization system, where we moved away from authenticating our own machines and now only need to authenticate machines run by other people on other internal networks. You might wonder why we used to authenticate our own machines on our own network, or alternately why we were able to make the shift away from doing so (and if you're the right sort of person, you already have a guess).

The origins of our custom NFS mount authorization system predate me here, so I only know parts of the story, but as I understand it our old approach existed for a very simple reason. You see, back in the old days, what we now consider our own networks weren't just our own networks. Instead, the department's public networks used to be a mix of our machines and other people's machines, and it wasn't a split that was as neat as 'we get this /24, other people are on other /24s'. Instead, due to historical evolution, various people had hosts and small networks distributed all over this IP address space.

With networks that were effectively insecure against IP spoofing, we had to have some more effective way of verifying our own servers than merely their IP address. Hence our custom NFS mount authentication system. In fact, it may have first been used (only) for our own servers, and then only later extended to let other people's machines selectively do NFS mounts from our fileservers. But clearly this wasn't an ideal situation, and once we (the core services group) created the internal sandbox networks, we started getting people to move their machines from public networks into appropriate sandboxes. All of this was before my time; by the time I arrived, I believe the move was almost completely finished, with only a few real machines lingering around on the public networks that we (the core services team) used, although none of them was on the most important (and most central) /24.

(There are other groups who had and still have their own /24, but that's different; they're segregated from the subnets we have our servers on.)

Today, every non-us machine is long gone from our core networks, so we no longer have to worry very much about IP spoofing of our own servers. As a result, we could consciously shift the goals of the NFS mount authorization system in a way that let us set up a different implementation of it, with different priorities.

Written on 03 July 2018.
« Understanding the first imperative of a commercial Certificate Authority
The hardware and basic setup for our third generation of ZFS fileservers »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jul 3 00:38:58 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.