Eliminating Root with Sudo
Pages: 1, 2, 3

Now that you understand how sudo permissions are set, let's look at how to actually use sudo. Use visudo, and give your account privileges to run any command. (If you've installed sudo correctly you already have root, so this won't be a security issue.)

The first time you run sudo, sudo will prompt you for a password. Enter the password for your own account, not the root password. If you give an incorrect password, sudo will insult your typing abilities, mental facilities, or ancestry, and let you try again. After three incorrect passwords, sudo gives up on you. You'll have to re-enter the command you want to run.

Once you enter a correct password, sudo records the time. If you run sudo again within five minutes, it won't ask you for a password. After you don't use sudo for five minutes, however, you must re-authenticate. This makes work easier when you're issuing a series of commands under sudo, but times things out quickly in case you walk away from the computer.

When you're a regular user on a system with sudo, one thing you'll probably want to know is what commands the system administrator has permitted you to run. sudo's -l flag will tell you this.

# sudo -l
Password:
User mwlucas may run the following commands on this host:
    (root) ALL
#

If you had tighter restrictions, they would be displayed.

To run commands via sudo, just put the word "sudo" before the command you actually want to run. For example, here's how we would become root using su via sudo.

# sudo su
Password:
#

Using sudo to become root simply allows the senior system administrator keep the root password a closely-held secret. This isn't entirely useful, as with unrestricted sudo access junior administrators can change the root password. Still, it's a start towards keeping the system more secure, and towards implementing sudo for all commands.

You can run more complicated commands under sudo, with all of their regular arguments. For example, tail -f is excellent to view the end of a log file, and to have new log entries appear on the end of the screen. Some log files are only visible to root, or should be -- for example, the log that contains sudo use information. You might want to view these logs without bothering to become root.

# sudo tail -f /var/log/authlog
openbsd/usr/src/usr.bin/sudo;sudo tail -f /var/log/secure
Jul 29 13:24:19 openbsd sudo:  mwlucas : TTY=ttyp0 ; PWD=/home/mwlucas ;
           USER=root ; COMMAND=list
Jul 29 13:30:03 openbsd sudo:  mwlucas : TTY=ttyp0 ; PWD=/home/mwlucas ;
           USER=root ; COMMAND=/usr/bin/tail -f /var/log/authlog
...

You can choose to run commands as a user other than root, if you have the appropriate permissions. For example, suppose we have our database application where commands must be run as the database user. You tell sudo to run as a particular user by using the -u flag and a username. For example, the operator user has the privileges necessary to run dump and back up the system.

# sudo -u operator dump /dev/sd0s1

All this tracking and accountability is nice, but where does it account to? sudo messages are logged to LOCAL2. Each log message contains a timestamp, the name of the user, the directory where sudo was run, and the command that was run.

Jul 29 11:21:02 openbsd sudo:    chris : TTY=ttyp0 ; PWD=/home/chris ; 
         USER=root ; COMMAND=/sbin/mount /dev/fd0 /mnt

In the worst case, you can backtrack exactly what happened when something breaks. For example, if one of my systems doesn't reboot correctly because /etc/rc.conf is missing or corrupt, I can check the sudo logs to who touched it.

Jul 29 11:34:56 openbsd sudo:    chris : TTY=ttyp0 ; PWD=/home/chris ; 
          USER=root ; COMMAND=/bin/rm /etc/rc.conf

If everyone had been using su, or even using "sudo su" instead of sudo to run each individual command, I would have had no clue as to why the system broke. With sudo logs, once I get this computer up and running again I know who to blame. This alone makes sudo worth implementing.

Next time we'll learn about some of the more complicated and interesting sudo configuration options, plus a few of the common mistakes people make with them.

Michael W. Lucas

---

Read more Big Scary Daemons columns.

Return to the BSD DevCenter.