As I’ve said before, package management is the coolest feature in any GNU/Linux distro. Prime example are the dpkg/apt tools that are used in most Debian-based distros. Repository software has been tried and tested, and package management ensures that that software Just Works. Now of course, that’s not something you’d want to mess up.
To ensure that the package manager doesn’t interfere with software you installed “manually” (i.e. not through dpkg, apt-get, aptitude, synaptic, …), there’s an article in the Filesystem Hierarchy Standard that says everything you install manually should go into /usr/local (or /opt, actually) and not directly into /usr. Usually you can easily configure a software installer by setting something like “prefix=/usr/local” somewhere.
That’s half the story: you don’t want to install stuff manually and have the package manager overwrite half of it later. The other half of the story is that there’s often a reason why that stuff wasn’t available in the package repository – most likely it’s not as thoroughly tested yet. I want to protect the main system files from alpha-quality software.
Anecdotal: I installed a piece of beta software once that thought it was ok to temporarily replace /bin/bash by something else. Because the script was too simple, it didn’t properly change it back. At the next boot, everything was obviously broken, and for a day I had no idea how to fix it, because I wasn’t aware in the first place that that installer had gone anywhere near /bin. It could do so silently because I called the installer through sudo….
On Debian, there’s a “staff” group (I discovered that on this page) that has privileges that solve the problem: members of staff can install files under /usr/local but not anywhere else. It’s also there on Ubuntu (I just installed Hardy Heron, see previous posts), although it doesn’t show up in the gnome menu that deals with groups. You can see it though in /etc/group. Unlike on plain vanilla Debian, /usr/local however doesn’t have staff group-ownership set.
Here’s what I did (note – it’s what I did, not what you should do – don’t trust a random blogger! – read the man pages for all of the following commands):
sudo adduser staffer #you can enter any password you like, because...
sudo passwd -l staffer #disables the password, just like for the root account
sudo adduser staffer staff #adds staffer to the staff group
sudo chown -R root:staff /usr/local #set group-ownership like on Debian
sudo chmod g+w /usr/local/* #make writeable for staff members
sudo chmod -R g+s /usr/local #setgid
Note that the last two lines work for me because I’m on a freshly installed Ubuntu Hardy, where /usr/local is still practically empty. If it’s not empty, this may set the setgid bit on some files, rather than on the directories only. I’m not sure if that’s a good thing (opinions welcome!). Now when you try this
touch testfile #error because you don't have write permission
sudo -u staffer touch testfile #no error
sudo -u staffer rm testfile
sudo -u staffer touch testfile #error
That’s it, basically. So now, you can install to /usr/local as staffer instead of as root, and you’ll get an error message when the installer at hand is trying to be naughty, writing to somewhere else. What’s this “staffdo” in the title of this post about then? Well, to make things look neat, I added
alias staffdo='sudo -u staffer'
to my .bashrc file. And you read all the way down this page to find out… hope it wasn’t disappointing!