Enterprise Unix Roundup -- Tugging SCO's Strings Page 2
|Main||In Other News||Security Roundup||Tips of the Trade|
- A well-publicized DoS vulnerability in TCP/IP will likely be inspiring updates for a while. SGI and NetBSD are the first we've seen so far.
- Linux kernel updates continue to come in from Red Hat, Debian (1, 2, 3), and Trustix.
- Gentoo, Slackware, Netwosix, Debian, and FreeBSD patched various CVS-related vulnerabilities.
Tips of the Trade
Do you ever need to share management responsibilities with another admin on one of your servers? Ever wish there was a way to avoid giving up your precious root password so another admin could run just one or two commands? Consider sudo, which stands for "superuser do." Sudo provides a way to delegate the ability to run some commands (such as, for example, letting your DNS guru restart a DNS daemon after a configuration change) without giving away the farm. Under OS X, the usefulness of sudo is so well understood that the traditional su command (which allows users to log in as root) is not available by default, and the operating system takes administrative instructions only from an administrative user using sudo.
Column length constraints limit our painting of sudo's complexity to broad strokes.
Sudo's basic usage is very simple:
sudo ifup eth0, for example, allows a normally unprivileged user to run the command "ifup eth0" without necessitating root user privileges.
Depending on how sudo is configured, the user might be prompted for his own password before the command runs. This provides some extra security in case the assistant admin running the job wanders off to the soda machine while malicious crackers are roaming the cube farm.
Underneath that simple command syntax, though, is some pretty involved plumbing.
Sudo is driven by the file /etc/sudoers, which establishes several bits of information sudo relies on (such as which users belong to specific sudo-recognized groups). The hosts from these users may run commands as the root user, whether or not the users require passwords to run these commands (in case a malicious user comes across an unsecured terminal belonging to a sudo-enabled user), and it allows for aliasing of specific commands to save you some typing.
/etc/sudoers is involved enough that editing it with a standard text editor is discouraged: A program called visudo provides a way to edit /etc/sudoers with some syntax checking. Brush up on your vi before wading into visudo, though.
Sudo provides one other useful feature: Once a user has invoked it and entered her password, she won't have to re-enter it for a five minute window. This makes things a little more convenient for users who have to enter a series of commands, or who must re-enter a command they messed up.
Even if you don't have any other users on your system who need root access, consider using sudo for your own non-root unprivileged identity. (You do have one, right?) With sudo, you create a small firewall of hesitation against blithely entering the wrong command and carelessly taking out your root partition or bringing down your storefront's database backend. You also minimize the need to "become root," with its attendant perils, should you forget to log back out into your "real" identity.
If sudo isn't available on your system, it is obtainable from the project home page.