Sudo, Sudon’t: Decreasing the Cognitive Load

Last week I talked about the joys of using the “sudo” command to manage resources installed as “root” on Unix-like systems, and some of the unpleasant links you have to jump through in the name of security.

The context of the discussion was ActiveTcl’s “teapot”, which is a repository of Tcl library packages available to all Tcl programmers on the machine. That’s a very good thing; and it’s because the teapot serves all users that it’s installed in a central position that’s owned by “root”.

ActiveTcl comes with a program inevitably called “teacup”; teacup allows you to install new library packages from a repository on a web server into your local teapot, and if you install them into the default teapot then everyone on the machine can use them. But you have to use “sudo”.

Quill has a different model for external library packages. Your project keeps a list of the external libraries it needs in its “project file”, and Quill goes out and retrieves the libraries over the ‘net and installs them in the teapot. The following command retrieves all missing libraries:

$ quill deps update

Mind you, it’s still using “teacup” in the background…but it’s one command, rather than several. That’s the idea. But if you install them into the default teapot, which is owned by “root”, you need to use “sudo”:

$ sudo quill deps update

And that might or might not work, for the reasons I discussed last week: Quill needs to search for the “teacup” executable, and if “sudo” hides its environment variables, Quill can’t find it. And it’s bad idea anyway: the programmer has to trust that Quill isn’t going to do anything nasty (either accidentally or on purpose), and why should he have to worry about that?

The goal, then, is to arrange matters so that we don’t need to use “sudo” on a regular basis.

It so happens that ActiveTcl allows you to have an arbitrary number of teapots on your machine; and so the obvious solution is to create a teapot in the user’s home directory. Then we can use “teacup” to install any needed packages there, instead of into the central teapot. That turns out to work pretty well; and it takes just a few “teacup” commands to set it up:

$ teacup create ~/.quill/teapot
$ teacup default ~/.quill/teapot
$ sudo teacup link ~/.quill/teapot `which tclsh`

Quill can do the first couple, but that last one, “teacup link”, unavoidably requires “sudo”; and Quill can’t execute it for the user, for the reasons given above. What to do?

After a couple of false starts, I came up with the following.

First, the quill teapot command determines whether the current teapot configuration is adequate. If it is, and no “sudo” commands are needed, then there’s no more to be done.

Second, the quill teapot fix command outputs a “fixteapot” script that takes all necessary steps. The details will change from machine to machine but it’s going to look something like this:

/usr/local/bin/teacup default /home/will/.quill/teapot
/usr/local/bin/teacup link /home/will/.quill/teapot /usr/local/bin/tclsh
...

Notice that the “teacup” and “tclsh” executables are given their full paths, so that the “which” command isn’t needed, and the location of the new teapot is also given in full. There’s nothing to look up, no environment to worry about.

The programmer using Quill can then look at the “fixteapot” script and either run the whole thing using “sudo” or run the individual commands by themselves; it’s up to him and what he’s comfortable with. And no one ever needs to run Quill under “sudo”, which eliminates a major source of worries.