Configuring sudo: Explaination with an example



Configuring sudo

sudo is easy to configure and uses a straightforward syntax. You use the command visudo to edit the file /etc/sudoers. visudo is a wrapper around your favorite editor that does syntax checking on the file when you are finished editing it. By default, if you don’t have the EDITOR variable set, visudo will use the vi editor. Arguments of editors aside, it is easy to changege the editor that visudo calls. Simply type the following, as root, to use your favorite editor (in this example we’ll use emacs):

# export EDITOR=emacs; visudo

This will open /etc/sudoers in the emacs editor. You can use any editor you like… ankit, jed, vim, whatever.Now that you have the /etc/sudoers file open, it’s time to configure sudo.

sudo commands use a basic syntax. By default, the /etc/sudoers file will have one stanza:

root      ALL=(ALL) ALL

This tells sudo to give root sudo access to everything on every host. The syntax is simple:

user       host = (user) command

The first column defines the user the command applies to. The host section defines the host this stanza applies to. The (user) section defines the user to run the command as, while the command section defines the command itself.

You can also define aliases for Hosts, Users, and Commands by using the keywords Host_Alias, User_Alias, and Cmnd_Alias respectively.

Let’s take a look at a few examples of the different aliases you can use.

Host_Alias      LAN =,
Host_Alias      SRV =,,
Host_Alias      MAIL =
Here we've defined 3 Host aliases.
 The first we've given the alias of LAN, to signify our internal LAN, and in it we've placed two machines:

The second alias is SRV, to signify our web servers, and these are:

The final Host alias is MAIL, which signifies our mail server:

Next, lets define some User aliases:

User_Alias        WEBADMIN = ankit, sam
User_Alias        MAILADMIN = ankit, navan
User_Alias        BINADMIN = ankit, jon

Here we’ve also defined three User aliases. The first user alias has the name WEBADMIN for web administrators. Here we’ve define Ankit and Sam. The second alias is MAILADMIN, for mail administrators, and here we have Ankit and Navan. Finally, we define an alias of BINADMIN for the regular sysadmins, again Ankit, but with Jon as well.

So far we’ve defined some hosts and some users. Now we get to define what commands they may be able to run, also using some aliases:

Cmnd_Alias         SU = /bin/su
Cmnd_Alias         BIN = /bin/rpm, /bin/rm, /sbin/linuxconf
Cmnd_Alias         SWATCH = /usr/bin/swatch, /bin/touch
Cmnd_Alias         HTTPD = /etc/rc.d/init.d/httpd, /etc/rc.d/init.d/mysql
Cmnd_Alias         SMTP = /etc/rc.d/init.d/qmail

Here we have a few aliases. The first we call SU, and enables the user to run the /bin/su command. The second we call BIN, which enables the user to run the commands: /bin/rpm, /bin/rm, and /sbin/linuxconf. The next is the SWATCH alias which allows the user to run /usr/bin/swatch and /bin/touch. Then we define the HTTPD alias which allows the user to execute /etc/rc.d/init.d/httpd and /etc/rc.d/init.d/mysql, for web maintenance. Finally, we define SMTP, which allows the user to manipulate the running of the qmail SMTP server.

Now you have to define how they all work together. This is where you give everyone permission to use certain commands on certain hosts. We do this with the same stanza we initially saw at the beginning, which gave root the ability to run everything on every host as root. Obviously, we want to limit access somewhat here. Here’s a sample based on the aliases we looked at previously:

ankit          ALL = NOPASSWD: SU
sam          LAN = BIN

This may take a little explanation, but it’s really easy to follow. The first stanza tells sudo to allow those users defined in the alias WEBADMIN (Ankit and Sam) to restart Apache and MySQL (defined in the alias HTTPD) on the systems defined by the SRV alias (the web servers). This means that on the systems in the LAN or the mail server, Ankit and Sam do not have access to do this, only on the three systems defined in the SRV alias.

The second tells sudo to allow the users in the MAILADMIN alias (Ankit and Navan) to restart qmail on (defined by the MAIL host alias).

The third tells sudo to allow the users in BINADMIN (Ankit and Jon) to access the commands in the BIN and SWATCH aliases (ability to manipulate the RPM database as root, remove any file, execute linuxconf to configure the system, run swatch, and use the touch command as root) on all systems.

The fourth tells sudo to let Ankit, who is our main sysadmin, to use the SU alias (to run su) on all machines without entering a password (more on this in a moment).

And the final stanza tells sudo to allow Sam, who is sometimes required to do maintenance on the LAN machines, to run the commands in the BIN alias on the machines in the LAN alias.

So what does this all mean, from your point of view? Well, Ankit is pretty much able to do anything. Having su access on all machines via sudo grants him this right. But he’s our main sysadmin and knows the root password anyways, so this is a matter of convenience for him. It allows Jon to run administrative commands such as linuxconf and rpm on all systems. He’s Ankit’s right-hand man. But he doesn’t have access to stop/start the web, MySQL, or qmail servers. Navan can stop and start qmail, however. But that’s about all she can do. Sam, on the other hand, can stop and start Apache and MySQL on the web server, and he can also do some administrative work on the LAN (via rpm and linuxconf). But he has no other rights on any machine.

You’ll have noticed the NOPASSWD keyword above. Each user, when using sudo, must enter their own password. For instance, when Navan wants to restart qmail, sudo will prompt her for a password. She enters her own password, not root’s. This tells sudo that it is executing the command for the right person. But, in Ankit’s case, he’s lazy and doesn’t want to type his password all the time, and since he’s the fellow writing the sudoers file, he decided to give himself NOPASSWD rights to when he runs su. So when Ankit runs su, he doesn’t have to supply a password, but when he runs linuxconf (for example), he does.

Already, you must realize the flexibility that sudo provides. With one single file, you can define access rights to multiple machines for multiple users. The only thing you need to do is have the file shared across your network. You can do this by using tools like rsync to synchronize the file, or you can use NIS to do it. Either way, you will only need to maintain one sudoers file for all systems.

Sudo also provides a means to track users that utilize it. By adding a specific stanza to your /etc/sudoers file, you can have sudo write to a specific logfile for you to audit. For example:

Defaults      logfile=/var/log/sudo.log, log_year

Will write sudo’s activities to the /var/log/sudo.log file. This file will look something like this:

May  1 13:44:06 2009 : ankit : HOST=mario : TTY=pts/3 ; PWD=/home/ankit/mail ;
    USER=root ; COMMAND=/bin/su
May  2 13:34:59 2009 : jon : HOST=smokie : TTY=pts/4 ; PWD=/var/www/html ;
    USER=root ; COMMAND=/bin/rpm -ivh

Here you can see that on May 1st, Ankit used the su command on the host mario. Likewise, you can see that on the 2nd, Jon decided to install ucd-snmp and ucd-snmp-utils on the host smokie. This makes for an extremely useful means of tracking who is doing what via sudo.

You don’t necessarily need to make the users be root in order to use sudo. If, for instance, you were running eggdrop under the uid of some other user (for example, someone named Jason), you could tell sudo to use the id of another user rather than root. For example, you may use something like this:

Cmnd_Alias     IRC = /home/Jason/bin/eggdrop, /home/Jason/bin/irc/ircd
ankit   = (Jason) IRC

This will let Ankit execute eggdrop and ircd in Jason’s home directory as if he were Jason, and not root, on the machine with the hostname of black.