One of my favourite tools is sudo, a program that many users will be familiar with. Both Ubuntu and OS X popularized sudo by making efficient and default use of the program. Sudo allows regular users to perform commands as other users.

Some lax defaults, such as allowing certain users to perform any commands as root, have become the norm, but sudo offers much more than that. Granted, for a single-user system, perhaps allowing all commands to be executed as root makes sense; if nothing else, it prevents users from having to run with a full root shell and forces them to pause and think about what they’re doing when sudo prompts for a password before performing the requested action.

The nice thing about sudo is that it offers an audit trail, and for that reason it makes sense to use sudo instead of simply using su to become root. Certainly, using su has its advantages if a number of things need to be done as root. In that instance, I would argue that using sudo su – instead of su- makes more sense; for one, it allows /bin/su to be stripped of the suid bit (turning it from a suid root program to a regular program executable only by root), and it provides an audit trail so that you can see, not only when su was called to become root, but also by whom.

Having said that, sudo offers a number of means to further delegate tasks that users need to perform as root. For instance, if a user needs to be able to install packages on a system, but does not require full root privileges, instead of giving them those full privileges, simply delegate with sudo. Edit /etc/sudoers with visudo (which performs syntax checking) and add:

Cmnd_Alias    SCRIPT = /usr/local/bin/script, /usr/local/bin/script2

%admin        ALL = (qa) NOPASSWD: SCRIPT

This example illustrates a few different things that can be done with sudo. The first is the Cmnd_Alias command, which allows us to assign aliases to commands. In this case, the SCRIPT alias is linked to two commands: /usr/local/bin/script and /usr/local/bin/script2. Now, instead of referring to both scripts, only the alias is needed.

The second line illustrates a number of features. The first is group assignment; by using %admin the following commands are applicable to any user in the “admin” group. To refer to a specific user, use their username — groups are always prefixed with the % character.

The ALL indicates that this command is available on all hosts. Using NOPASSWD tells sudo that the user’s password is not required, otherwise the user would have to authenticate to sudo with their password. Finally, the (qa) SCRIPT indicates that the commands associated to the SCRIPT alias may be executed, but only as the user qa. Note that this means those scripts will be run with the privileges of the qa user rather than root.

In short, that line indicates that any users in the admin group, on any host, may execute the scripts /usr/local/bin/script and /usr/local/bin/script2 as user qa, without having to enter their password.

This small sampling shows the flexibility of allowing sudo to delegate privileges to users. Instead of providing blanket all-or-nothing access, sudo can fine-tune privileges so that those administrators dealing with Web services may have root privileges to do things such as edit Apache configuration files, restart the Apache service, and possibly interact with a database such as MySQL, all with root (or with another user) privileges; others have regular user permissions to the rest of the system.

Get the PDF version of this tip here.

Delivered each Tuesday, TechRepublic’s free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!