Posts Tagged 'sudo'

How to close a sudo session, and why online man pages are useful

Apologies if this information seems slightly trivial – the thing is, it took me a few moments to find it, so in that sense it wasn’t entirely trivial… :)

I wanted to know how to end/close a sudo session – in many cases it seems unnecessary to leave your system “exposed” for the length of the timeout, but changing the timeout would be inconvenient at other occasions. So I searched the web, searched the man page, and didn’t find the answer with the keywords “close” or “end”.

The solution is of course to actually read the man page, and find out that better keywords would have been “kill” or “invalidate”. With those you would have quickly learned that “sudo -k” ends your session. There’s also “sudo -K” for “sure kill”, I’m not entirely sure about the subtle difference between these two.

Let me also seize the opportunity to link to the Ubuntu Manpages Repository, which I believe is a fairly new facility. You can find the man pages for sudo there, for example. I realise it’s a bit odd to use online man pages, and I personally much prefer reading them in a console with the fixed-width font they were intended for. But there’s one really good thing about online man pages: they will finally be able to acquire the Page Rank that they deserve – after all, most questions we ask Google about our OS should have a man page popping up in first position. So I’ll try to consistently link to the relevant man pages from now on…


Staffdo: my handicapped version of sudo

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

cd /usr/local
touch testfile #error because you don't have write permission
sudo -u staffer touch testfile #no error
sudo -u staffer rm testfile
cd /usr
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!