Now that you understand how
sudo permissions are set, let's look at
how to actually use
visudo, and give your account
privileges to run any command. (If you've installed
you already have root, so this won't be a security issue.)
The first time you run
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.
-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
# sudo su Password: #
sudo to become root simply allows the senior system administrator keep the
root password a closely-held secret. This isn't entirely useful, as
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.
sudo to run as a particular user by using the
-u flag and a
username. For example, the operator user has the privileges necessary
dump and back up the system.
# sudo -u operator dump /dev/sd0s1
All this tracking and accountability is nice, but where does it
sudo messages are logged to LOCAL2.
Each log message contains a timestamp, the name of the user, the
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
/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
sudo configuration options, plus a few of the common mistakes people make with them.
Read more Big Scary Daemons columns.
Return to the BSD DevCenter.