Sudo Voodoo

Using the root account for day-to-day work is a bad idea. It's better to use sudo to act like root when you need to do a little system administration. Ken Hess shows you how.

A Linux system has two kinds of users: ordinary users and the root user. Each ordinary user has a robust set of permissions to manage his or her own files (and files that belong to a group that he or she is a member of), but an ordinary user cannot affect system configuration, start or stop essential services such as the SSH daemon, and cannot reserve a so-called privileged port, or any networking port numbered less than 1,024. The root user, though, is free to access and modify any file, perform any task, and affect the system at will.

Of course, as Spider-Man says, ‘With great power comes great responsibility.’ root must be cautious, because a small typo can lead to disaster. For example, there’s a big difference between the command rm -rf /a and rm -rf /. Given the potential for such accidental cataclysms, it’s considered a best practice to never log in as root, lest you forget or misdirect the (remaining in the Marvel Comics universe) Thor-like power you wield.

Indeed, many Linux distributions preclude root logins, preferring instead to grant the initial user the right to act like root when necessary. This special privilege, which can be extended to other users on the system, is managed via the sudo (pronounced ‘soodoo’) utility. sudo controls who can act like root, and can further control what a user can do as root.

When a task requires root powers, and assuming the user has the right to perform the task at hand as root, the user simply prefaces the command with sudo. For example, say the /tmp directory is filled with oodles of scratch files created by a myriad of users. While each user can only remove his or her own scratch files, a user with the right to run rm as root (as dictated by sudo) can clean the entire directory with one command:

$ whoami
$ sudo rm -rf /tmp/*

The user khess has limited rights. However, prefacing the command with sudo invokes the command as if the user was root. Yes, you can still make a typo and remove all of /tmp, but sudo minimizes the use of root privileges and hence the risk of mistakes.

So su Me

sudo is something of a specialized version of another ‘alter ago’ application named su, short for ‘substitute user.’ su allows one user to temporarily act like another. Specifically, su runs a shell with substitute user and group IDs. Any user may issue /bin/su and switch to any other user account, including root, if the substituted user’s password is known.

$ whoami
$ su - bob
$ whoami
$ exit
$ whoami

The - option starts a login shell as the user bob. Once you type Bob’s password at the prompt, you are bob. Every file you create or process you start is owned by Bob. If you exit the login shell spawned by su, your original user and group IDs are restored, as shown above.

su can also be used to become root just as it’s used to become bob, or any other user.

$ su -

Assuming you know the root password, su - (the username is omitted) changes your user and group ID to root.

However, disseminating root’s password isn’t recommended because it poses a serious security risk. If the password fell into the hands of a malcontent, the system (or many systems) could be compromised.

To enhance the security of su, change the permissions of /bin/su to allow only root and group admin access:

# chgrp admin /bin/su
# chmod o-rwx /bin/su
# ls -l /bin/su
r-sr-x--- root admin '

Here, read and execute rights have been rescinded for ‘other’, and the group owner has been changed to limit access to the members of the admin group. This is the recommended setup for a multiuser system.

Who Do You sudo?

Even if su is restricted, it’s use still requires the root password. A leaked password is one risk, but changing the root password frequently may also lead to problems, as passwords, especially well-constructed cyphers, are difficult to remember. sudo was invented to solve these two issues and more. sudo catalogs who can become root and what the user can run as root. The catalog is maintained in /etc/sudoers.

To determine if you have sudo privileges, run the command sudo -l.

$ sudo -l

Here, you must enter your password to authenticate yourself, preventing a miscreant from abusing your privileges. If you do not have sudo access, you’ll receive a message similar to:

Sorry, user fred may not run sudo on this host

Otherwise, sudo presents the list of commands that you have rights to execute:

$ whoami
$ sudo -l
User fred may run the following commands on this host:
    (root) /usr/local/bin/apachectl

As you can see, fred can control the Apache HTTP Server daemon via apachectl as root.

After you invoke sudo and provide your password, sudo provides a ‘ticket’ good for five minutes of access. During these five minutes, you need not provide your password again to run additional commands via sudo.

In fact, each command you execute within five minutes extends the five-minute window. However, if you fail to issue any command using sudo within five minutes, the ticket expires and you must re-authenticate to re-use sudo. A timeout precludes others from usurping your privileges while you’re out to lunch or otherwise away from the computer.

Here’s an example of a series of sudo commands to copy and edit a file and restart Apache:

$ sudo cp -p index.html index.html.20070511
$ sudo vi index.html
$ sudo apachectl restart

You must prepend each command with sudo. If you don’t prepend the command with sudo, the system assumes you are issuing the command as yourself.

How Do You sudo?

As shown above, sudo need not be the key to Pandora’s Box. A user can be restricted to run a collection of commands. fred, for instance, can stop, start, and restart Apache via apachectl, but cannot run rm or vi.

To edit the sudo catalog, /etc/sudoers you must use a special editor named visudo. The catalog has a somewhat complex and specific format. Listing One is an example sudoers file.

Listing One: A sample /etc/sudoers file

# User privilege specification
root    ALL=(ALL) ALL
%admin  ALL=(ALL) ALL

# Uncomment to allow people in group wheel to run all commands
%wheel        ALL=(ALL)       ALL

  • The first field is either a user name, such as strike, or a group name, such as %admin or wheel.

  • The second field specifies a list of hosts. (Since the same sudoers file may be copied to all machines on the network for consistency, you may allow different privileges on different hosts.) The abbreviation ALL matches any hostname.

  • The third field (the one in parentheses following the =) enumerates usernames or IDs. A command can run as any of the listed users. This is valuable when you need to stop, start, restart, kill a process that isn’t owned by root. (Of course, you can kill any process as root, but you may not want to start any process as root, inadvertently giving a simple service root privileges.) Again, ALL matches any user.

  • The fourth field lists the commands that can be run.

Or, put more simply, the fields are:

Username    Hosts=(Usernames or UIDs)) Commands

Separate multiple entries for any of the latter fields with commas. (You can refer to the sudoers man page for details.)

Hence, this user privilege specification:

root    ALL=(ALL) ALL

allows the root user to run all commands on all hosts as any user. Similarly, if you’re fred and use a desktop Linux system, /etc/sudoers probably contains an entry like this:

fred    ALL=(ALL) ALL

This is reflected by sudo -l:

$ sudo -l
User fred may run the following commands on this host:
    (ALL) ALL

To run a command as a user other than root (assuming sudoers permits it), use the -u option:

$ sudo -u nobody /etc/init.d/some_service restart

This restarts some service as the user nobody. To issue more than one command as another user, the switch must be used each time you invoke sudo. If you omit -u, root is assumed.

Sudo’s and Sudon’ts

Here’s a list of things to do and to avoid when you setup and use sudo. Do:

  • Specify the full path to all commands for aliases and single commands.

  • Use aliases for hosts, groups, and commands. (See the man page to create aliases.)

  • Follow the principle of ‘least privilege’: Only grants those rights that are needed and nothing more, and be explicit.

  • Check the log files /var/log/auth.log or /var/log/secure often for sudo usage and violations.


  • Don’t try to exclude commands from ALL. (Again, use aliases.)

  • Never grant ALL=(ALL) ALL to anyone.

  • Do not specify the NOPASSWD modifier for regular users. NOPASSWD allows a user to use sudo without password authentication.

Sudo You Think You’re Foolin’?

A great many problems can be solved by using sudo. Best of all, you don’t have to give the root password to anyone other than administrators or the system owner. Clever use of sudo can track privileged use on a system.

However, sudo can also create exploits if you allow users too much access. For example, if you permit a user to have access to ALL, the user can become root permanently (until their next login, anyway) using the command sudo su - or sudo /bin/bash. Implementing sudo policies should be a well- thought out undertaking. sudo can either bring much comfort to nervous administrators or much heartache to cavalier ones.

Comments on "Sudo Voodoo"


It’s pronounced sue-doh, not soodoo.


It’s pronounced both ways, and that’s ok.


Q) How do you pronounce `sudo’?
A) The official pronunciation is soo-doo (for su “do”). However, an alternate pronunciation, a homophone of “pseudo”, is also common.

from: http://www.gratisoft.us/sudo/troubleshooting.html


soodoo, soda, sodough, sewdo, samo-freakin’-whamo, they all sound good but who’s gonna get you there w/o going root? only SUDO!


I like to use sudo but can find it annoying when it feels like it is always asking me for my password. To make this happen less frequently I increased the time after which it will ask for the password again to a reasonable time (remember too long would also be less safe).. This is done in /etc/sudoers by adjust the flag ‘timestamp_timeout’.




What would be the best solution (with sudo) to provide file editing capabilities to regular users without giving “sudo vi /path/file”? (Because you could run a shell as root from vi). thx


no one requires their sys admins to use sudo, correct ? Only users who need to perform a specific task.

How do you track what your sys admins are doing ?


“no one requires their sys admins to use sudo, correct ? Only users who need to perform a specific task.

How do you track what your sys admins are doing ? “

Where I work, even I (sysadmin) use sudo. I could get around it easily enough but if I am going to be having everyone else use it then I need to lead by example and use it to.


To prevent a user from shelling out with vi (which is vim on my machines), use the “-Z” option or “rvim” which is the same thing. If your vi is different, run “man vi” to find out how to make it restricted.


How can this be implemented in a NIS environment?
I want to create a group of administrators who can have certain sudo priveleges distributed to all of the systems in my NIS domain.


There is an LDAP Implementation for sudo.


Officially it is soo doo, because you are doing something as another user. I pronounce it both ways but soo doo more often than before. People understand it both ways though. Kind of like SQL. Do you say it ess-cue-ell or sequel?


thanks for this article


cool when if u have more inf on this plz mail me.. i’m a begginner


It’s not just for root access though. You can use it to grant account access from one user to another. For example, logging in as user1 and then entering “sudo -i -u user2″ gives you an interactive session as user2 without having to know user2′s password (assuming appropriate sudoers configuration). So for example if user2 is a production account running say the accounting system and user1, a support person, needs to login to the production accounting account they can do so without knowing the production account password and their access is logged (i.e., user user1 logged in as user2 at ).
One issue I’ve encountered with sudo is in situations where you need to tunnel X-Windows. For example, user1 uses “ssh -X host1″ and then once logged into host1 (with X DISPLAY setting appropriately automatically handled by ssh -X) then needs to sudo to user2 and run an X-Windows client the DISPLAY variable doesn’t seem to get propagated. Setting the DISPLAY variable manually to the value from the tunneled session (localhost:10.0) and then running the X-client application results in “X11 connection rejected because of wrong authentication”.


The use of acronyms has gone to insane levels in all of the IT World. SQL is three letters S, Q, and L. That’s how it’s pronounced. People who insist on calling it sequel are TARDS in my opinion. Trying to make words when it’s just as fast to say and even faster to write the letters doesn’t make one seem cool or computer savy. It makes them silly. I won’t say a word about sudo because I have the utmost respect for the linux Guru’s. They can call it what they want.
It’s funny though that my friend who got me started on Linux kept telling me to try installing a Digital Subscriber Line on my thumbdrive? DSL (Damn Small Linux):-)

Thanks for the informative article! It beats trying to figure out man pages.


Thanks for nice article. Very informative.


Thanks for the blog.Really looking forward to read more. Cool.


Useful info. Fortunate me I found your website unintentionally, and I’m stunned why this accident did not took place earlier! I bookmarked it.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>