Remembering Evi Nemeth: The woman that saved "sudo"

Technology website The Register called it. With the search called off, we must presume that Evi Nemeth is no longer with us. Their obit, "Godmother of Unix admins Evi Nemeth presumed lost at sea", gives an excellent overview of her life and influence.

In the coming months there will be many memorials and articles written about Evi, most by people that knew Evi better than I. That said, I'd like to share something that most people don't know.

Evi saved "sudo".

Sudo has joined popular culture (or at least popular geek culture) thanks to the famous XKCD cartoon: sudo make me a sandwich. This has lead to other sudo references, even a company cafeteria (see picture).

I think most people understand sudo as "a Unix/Linux command that forces something to happen, or forces a computer to do something" which is pretty close. What it really does and the historical impact it made needs to be known.

The Unix operating system (and Linux, which is its clone) permits many users to log in to a computer at the same time. Each user is prevented from mucking with other people's stuff. However there is one user called "root" which is the "super user" and can meddle with all files, unrestricted. This is the "janitorial" account used by system administrators to fix things, install and uninstall software, reboot, and so on. Think of it as cardkey at a hotel that opens all the doors.

The "root" account has a password just like all accounts. Before sudo (1985) was popular (1995?), the system administrators would memorize their own password and also the "root" account password. When they needed to do maintenance they would log into the root account. There is even a command called "su" (super user) which makes it easy to temporarily switch to the "root" account for this reason. "su" requires you to enter the password for the account you will become. Therefore to become root you had to know the root account password.

"su" works just fine when you have one big Unix machine for the entire company, department or campus. It is easy to share the password among just the people that should have such heightened privilege.

That's fine for the 1980s where there may be 1 or 2 big computers for a department shared by hundreds of users. The users themselves do not have "root access" just as the customers of a hotel do not get the "master passkey". However with the workstation and PC revolution it was common to have hundreds or thousands of Unix computers in an organization. Typically they would have the same password for "root" on all of them. Again, this was fine because there may be 3-4 system administrators trusted with the password. But what if someone requires to do something as root on their own machine? With computers now owned by individuals, not departments, this caused a problem. You couldn't tell the owner of a machine the root password because then they'd know the root password for every machine in the network!

A number of terrible solutions were created. One was to set a different "root" password on each workstation so the owner could know the password, but then the sysadmins would have to memorize hundreds of passwords, store them somewhere (which is insecure), or just give up control of all the workstations that they were hired to control.

Another solution, popular at Rutgers, was called "slide". If your account had access to the "slide" command, you could "slide into root" without being prompted for a password. This was bad for many reasons but I recall two that were most important: first, since it didn't ask for a password it basically made your account as powerful as "root", which defeats the purpose of having users "compartmentalized" from each other. It also meant that if you walked away from your computer, someone could easily slide into root without permission. (nobody locked their screen back then)

Then there was this brilliant command: "sudo". It permitted fine-grained delegation of power with centralized control. It was like "su" but instead of asking for the root's password it asked for your password. It then decided if you were allowed to "become root" based on an authorization matrix created by the system administrators. No need to tell additional people the root password or create additional root passwords. It was "fine grained" meaning that the sysadmins that configured sudo could specify if a particular user could run a specific command as root (like, maybe just give people permission to eject CD-ROMs... something that only root was allowed to do for reasons that are too long to explain here) or full access to everything. It had "centralized control" in that the system administrators could configure sudo in a way that was maintainable and wouldn't get sloppy.

In the move from big, central, serveres to a world of workstations, sudo was a miracle.

It was so radical, in fact, that I didn't quite get why anyone would use it. I was in an environment that was treating 120 workstations the way we used to treat big centralized computers: three sysadmins that all knew the root password and none of our users did, nor could they do "root things" on their own machines. [You may be wondering... After being asked to eject a CD-ROM from their computer for the millionth time, we made a special command that enabled self-service ejects. If I had sudo I could have changed the authorization matrix, not spent a week writing code to make that command.]

So how does Evi play into this?

Sudo was first conceived and implemented around 1980 at SUNY/Buffalo. Sudo wasn't released publicly until about 1985. Between 1985 and 1991 Colorado University at Boulder and others kept improving it. There were many versions floating around, each with slightly different features, compatibility (or lack there of) with different Unix variants, and security problems. There was an "official" version but, for lack of a better term, was abandoned and went years without a new release.

Eventually the Colorado University at Boulder variant became the official version thanks to their leadership role, setting up a website and so on. This was the work of Todd C. Miller. Todd had been contributing to the project since 1992.

Todd recently told me in email that Evi "really had a major impact" on his life. Evi encouraged him to modify sudo "and was a major factor in its acceptance due to the inclusion of sudo in her System Administrator's Handbook."

Evi also advocated the use of sudo at the Usenix LISA tutorials. Every year at Usenix LISA she would teach a tutorial called "Hot Topics in System Administration". Before the internet, this was the best way to find out what the new tools in Unix system administration were. People would come to LISA just to see what new stuff was going to be revealed. This is where I first heard about amd (the automount replacement), sudo, RRDtool, ISC DHCP, and many other technologies that were new then, but soon became "standard" for any Unix/Linux system.

In that way, Evi saved sudo. She had the foresight to see that the future of Unix/Linux was distributed workstations and that sudo was an important step to making that vision a reality. She advocated that people use sudo via her books, articles, and training thereby giving it the momentum that was required to break through the cacophony of lessor solutions.

sudo is now a part of the "base install" of nearly ever Unix/Linux system available today. It is the standard way to run things as root. As a result managing systems is much easier and more secure.

We can thank Evi for that.

On a more personal note: when I think of Evi the picture in my mind is from the first time I met her. I was a wide-eyed young sysadmin in a class she taught at LISA. She was standing at the front of the packed classroom. A grey haired, diminutive woman passionately educating the first large generation of Unix/Linux system administrators about how to create the future by staying on top of the latest tools and techniques. Thank you, Evi!