Modern versions of Unix are more adjustable than they used to be

November 6, 2013

One of the slow changes in modern Unix over the past ten to fifteen years has been a significant increase in modularity and with it how adjustable a number of core things are without major work. This has generally not been something that ordinary users notice because it happens at the level of system-wide configuration.

Undoubtedly this all sounds abstract, so let's get concrete. The first example here is the relative pervasiveness of PAM. In the pre-PAM world, implementing additional password strength checks or special custom rules for who could su to who took non-trivial modifications to the source for passwd and su (or sudo). In the modern world both are simple PAM modules, as is things like taking special custom actions when a password is changed.

My next example is nsswitch.conf. There was a day in the history of Unix when adding DNS lookups to programs required recompiling them against a library with a special version of gethostbyname() et al. These days, how any number of things get looked up is not merely something that you can configure but something you can control; if you want or need to, you can add a new sort of lookup yourself as an aftermarket do it yourself thing. This can be exploited for clever hacks that don't require changing the system's programs in any particular way, just exploiting how they work (although there are limits imposed by this approach).

(Actually now that I'm writing this entry I'm not sure that there have been any major moves in this sort of core modularity beyond NSS and PAM. Although there certainly are more options for things like your cron daemon and your syslog daemon if you feel like doing wholesale replacement of programs.)

One of the things that these changes do is they reduce the need for operating system source since they reduce your need for custom versions of operating system commands.

(Of course you can still wind up needing OS source in order to figure out how to write your PAM or NSS module.)

Sidebar: best practices have improved too

One of the practical increases in modularity has come from an increasing number of programs (such as many versions of cron) scanning directories instead of just reading a file. As we learned starting no later than BSD init versus System V init, a bunch of files in a directory is often easier to manage than a monolithic single file because you can have all sorts of people dropping files in and updating their own files without colliding with each other. Things like Linux package management have strongly encouraged this approach.


Comments on this page:

By David at 2013-11-06 04:17:24:

When you say "I'm not sure that there have been any major moves in this sort [...] beyond NSS and PAM", its interesting to note that both PAM and NSS originated on Solaris in the mid-90s. Here's a speculative explanation:

Sun workstations were widespread at the time, both in University labs and commerical organizations using Unix. This made adoption of ideas from Sun like these easy: sysadmins were familiar with the concepts, and free software developers had reference implementations available to work against. And at the same time, commercial Unices were standardizing to meet the challenge from NT.

But within a few years, the context had changed a lot. PC-based workstations became performance competitive with the RISC workstations, while being a lot more cost-effective. Linux and the BSDs became mature enough for widespread adoption within Universities. And NT delivered a version of Windows that was good enough for serious work. Commercial Unix on the desktop became much rarer everywhere, so de-facto standards were less able to emerge in the same way.

Since then, the Unix world has become more fractured in some ways. Commercial Unix lost its authority, the BSDs and Linux treat ideas from the other camp with a certain amount of distrust, and Linux itself has become somewhat fragmented among the various distros (to the point where there is no longer a standard init system).

Would crypt() be something that has been made modular as well?

Originally the format of the passwd/shadow file's password field was always assumed to be a particular length and format. By adding the "$1$", PHK allowed for future modularity that eventually gave us bcrypt and the SHA2-based hashes:

http://www.freebsd.dk/sagas/md5crypt.html

Personally I'd like the next hash to be a scrcypt /SRP combination. Scrypt would give a good defense against offline brute force attacks, while storing the SRP verifier gives you Diffie-Hellman built right in the OS.

By cks at 2013-11-06 15:22:52:

What I'm mostly thinking about here is increases in what I'll call 'externally usable' modularity, things that I as a sysadmin can plug into or adapt or reconfigure. Crypt()'s increased modularity is great as a general thing but I think it's more internal modularity than external modularity. On many systems you can't add your own new crypt() password format in the same way that you can add a new NSS or PAM module; instead you have to explicitly add it to the standard library and rebuild.

Written on 06 November 2013.
« How writes work on ZFS raidzN pools, with implications for 4k disks
Why you might not want to use SSDs as system disks just yet »

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

Last modified: Wed Nov 6 01:30:03 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.