Wandering Thoughts archives

An init system has two jobs

Ever since System V init came on the scene, it's been clear that a Unix init system really has not one but two jobs. I don't quite mean this in the sense of init's historical roles but in a more high level sense of what people want from their init.

The first job is to be init, PID 1, with everything that that implies. Init starts things on boot, supervises processes, does things on shutdown, doesn't crash, and so on. This job is well recognized and understood and as a result, essentially any real init system is pretty good at it (although some are better around the edges than others). Certainly any of them will get the job done.

The second job of an init system is to help you manage the init system and the services and processes it controls. This is the job not of starting and stopping things but of letting you control what is started and stopped and so on. Not being an init system, but controlling the init system. This job is much less well recognized and as a result much more immature (partly because the job only really started when System V init showed that perhaps there might be a better way to do it than editing /etc/rc.local and running by now). daemons by hand, and even then it stagnated for quite a while).

Init systems are all over the map when it comes to the second job. Some of them still barely acknowledge that it exists; some sort of handle it; some are actually pretty decent. A few are genuinely pleasant. Some, unfortunately, are wretched at it. In short, this is the area where init systems really distinguish themselves from each other.

(There are differences in how init systems approach the first job and some of them do make a difference, but my view is that it's nowhere near as big a difference as the second job creates.)

As a system administrator I find this kind of an unfortunate state of affairs, since that second job is something we get to deal with on a regular basis. I really wish most init systems paid more attention to it.

The fundamental problem that created su

There is a fundamental problem that su, sudo, and many other tools are used to try to solve. Actually there are two problems, but su only addresses the one so let's start with it.

The first problem is that you have the right to exercise all power but you do not normally want to exercise that power. Most of the time you want to have no power and perhaps some of the time you might like to have some focused power; this is primarily to limit the scope of accidents and mistakes. If you are duly authorized to do everything on a Unix system, well, perhaps you could just give your account a UID of 0 but almost everyone agrees that that would be a terrible idea. It is much safer not to have all power almost all of the time and to exercise that power for as short as possible a time and in as limited as possible a way.

(Well, really it is 'feasible' instead of 'possible'. There is a balance of tedium between free exercise of power and significant amounts of work.)

Or in short: su is there to limit a sysadmin's power, not increase it. Su is there to let you do things without the powers of root. Because su can give you power temporarily, you do not need that power permanently.

(I suppose technically you could say that su is there to increase auditability, since you can su to root and thereby leave a trace of who you used to be instead of having to log in as root in some way.)

The other problem is that you have the rights to some powers but not other powers and you must somehow be granted selective access to only those powers you have a right to. This problem is solved by setuid on selected programs, sudo in various forms of usage, and with things like RBAC. Su does not solve it directly.

These two problems are almost completely orthogonal. A solution for access to limited powers for people authorized for them does not really help people who have the right to all power but do not want any power most of the time. Perhaps in the right situation it can make their life somewhat safer if people (or scripts) diligently remember what operation needs what limited power and that limited power can be kept turned off most of the time.

(And a solution to access to limited powers does not necessarily mean that those limited powers can be turned off when you don't want them. They may be always-on enhancements to an otherwise normal account.)

This is why RBAC or an equivalent is not a replacement for su for fully root-authorized sysadmins. In fact in some ways bare RBAC is an anti-replacement, if your ordinary account winds up with more intrinsic powers than before.

This is a generic problem for any system of enhanced powers. Unless the additional powers are harmless, the sensible default state is that you do not have the powers despite having the right to them; you want an explicit activation step for safety (and you may want this activation step to involve an additional challenge or secret for increased security). Su (and traditional UID 0 in Unix in general) is only unusual in that the powers are an all or nothing affair instead of selective.

(There are relatively few additional powers that are genuinely harmless. Powers that enable system changes are obviously dangerous but even mere information disclosure powers may give you normally private information that you don't want to know or should not know without real need.)

Vi's composability antecedent (or one of them)

These days the venerable vi editor is getting a bunch of praise for its genuine and core innovation of composable commands, such as in Mike Kozlowski's Why Atom Can't Replace Vim. I wholeheartedly support this; vi's command composability is amazing and powerful and I wish more programs used or even embraced the ideas behind it (as far as I know, vi's basically the only editor that's ever really done this).

But today I want to mention that vi's composability is not without antecedents, in fact antecedents in Unix itself. The antecedents are nowhere near as fully developed and nice as vi, but in them I think we can see the kernel of vi's idea (as well as some ideas that did not catch on in vi). In fact, one antecedent is even buried in vi itself. I am of course talking about the family of Unix line oriented editors that gave us ed, sed, and vi's ex mode.

Like vi itself, all of these editors revolve around a fundamental idea: you specify first text addressing and then the command to apply to whatever you've specified. Want to delete the next five lines? First you specify five lines as '.,.+5', and then you say to 'd' what you've just addressed. Learn a new addressing method and you can use all of the commands you know with it; learn a new command it works with all of the addressing methods you know. This is the same core engine as vi has, although in a much more primitive and limited form of both addressing methods and available commands.

(And if you want to see things that way you can think of Unix pipelines as a form of this idea. Clearly pipelines compose things together, although in a more general way than vi et al do.)

PS: to note this antecedent is in no way to take away vi's striking accomplishment in generalizing it and applying it to more sophisticated movement and addressing as well as more complex text manipulation, and also figuring out how it should all work in a visual, character based environment instead of the basic line oriented one that ed uses.

(See also the history of ed, which stretches back even before Unix.)