Sudo

The sudo command provides a simple and secure way to configure privilege escalation, e.g. letting normal users to execute certain (or all) commands as root or some different user, possibly without giving a password.

When you want some people to perform certain administrative steps on your system without granting them total root access, using sudo is your best option. With sudo you can control who can do what. This guide offers you a small introduction to this wonderful tool.

Granting Permissions
The  package allows the system administrator to grant permission to other users to execute one or more applications they would normally have no right to. Unlike using the setuid bit on these applications  gives a more fine-grained control on who can execute a certain command and when.

With  you can make a clear list who can execute a certain application. If you would set the setuid bit, any user would be able to run this application (or any user of a certain group, depending on the permissions used). You can (and probably even should) require the user to provide a password when he wants to execute the application.

Logging Activity
One additional advantage of  is that it can log any attempt (successful or not) to run an application. This is very useful if you want to track who made that one fatal mistake that took you 10 hours to fix :)

Configuring Sudo
The  configuration is managed by the  file. This file should never be edited through  or   or any other editor you might like. When you want to alter this file, you should use.

This tool makes sure that no two system administrators are editing this file at the same time, preserves the permissions on the file and performs some syntax checking to make sure you make no fatal mistakes in the file.

About this Guide
This guide is meant as a quick introduction. The  package is a lot more powerful than what is described in this guide. It has special features for editing files as a different user, running from within a script (so it can background, read the password from standard in instead of the keyboard, ...), etc.

Please read the  and   manual pages for more information.

Basic Syntax
The most difficult part of  is the  syntax. The basic syntax is like so:

Basic /etc/sudoers syntax

This syntax tells  that the user, identified by user and logged in on the system host can execute any of the commands listed in commands as the root user. A more real-life example might make this more clear: allow the user swift to execute  if he is logged in on localhost:

Live /etc/sudoers examples

Abig warningis in place though: do not allow a user to run an application that can allow people to elevate privileges. For instance, allowing users to execute  as root can indeed grant them full root access to the system because   can be manipulated to change the live file system to the user's advantage. If you do not trust your  users, don't grant them any rights.

The user name can also be substituted with a group name - in this case you should start the group name with a  sign. For instance, to allow any one in the  group to execute   :

Allowing the wheel group members to execute emerge

You can extend the line to allow for several commands (instead of making a single entry for each command). For instance, to allow the same user to not only run  but also   and   as root:

Multiple commands

You can also specify a precise command and not only the tool itself. This is useful to restrict the use of a certain tool to a specified set of command options. The  tool allows shell-style wildcards (AKA meta or glob characters) to be used in pathnames as well as command line arguments in the sudoers file. Note that these are not regular expressions.

Let us put this to the test:

The password that  requires is the user's own password. This is to make sure that no terminal that you accidentally left open to others is abused for malicious purposes.

You should know that  does not alter the   variable: any command you place after   is treated from your environment. If you want the user to run a tool in for instance he should provide the full path to  , like so:

Using Aliases
In larger environments having to enter all users over and over again (or hosts, or commands) can be a daunting task. To ease the administration of you can define aliases. The format to declare aliases is quite simple:

Declaring aliases in /etc/sudoers

One alias that always works, for any position, is the  alias (to make a good distinction between aliases and non-aliases it is recommended to use capital letters for aliases). As you might undoubtedly have guessed, the  alias is an alias to all possible settings.

A sample use of the  alias to allow any user to execute the   command if he is logged on locally is:

Allowing any user to execute shutdown

Another example is to allow the user  to execute the   command as root, regardless of where he is logged in from:

Allowing a user to run an application regardless of his location

More interesting is to define a set of users who can run software administrative applications (such as  and   ) on the system and a group of administrators who can change the password of any user, except root!

Using aliases for users and commands

Non-Root Execution
It is also possible to have a user run an application as a different, non-root user. This can be very interesting if you run applications as a different user (for instance  for the web server) and want to allow certain users to perform administrative steps as that user (like killing zombie processes).

Inside you list the user(s) in between   and   before the command listing:

Non-root execution syntax

For instance, to allow  to run the   tool as the   or   user:

Non-root execution example

With this set, the user can run  to select the user he wants to run the application as:

You can set an alias for the user to run an application as using the  directive. Its use is identical to the other  directives we have seen before.

Passwords and Default Settings
By default,  asks the user to identify himself using his own password. Once a password is entered,  remembers it for 5 minutes, allowing the user to focus on his tasks and not repeatedly re-entering his password.

Of course, this behavior can be changed: you can set the  directive in  to change the default behavior for a user.

For instance, to change the default 5 minutes to 0 (never remember):

Changing the timeout value

A setting of  would remember the password indefinitely (until the system reboots).

A different setting would be to require the password of the user that the command should be run as and not the users' personal password. This is accomplished using. In the following example we also set the number of retries (how many times the user can re-enter a password before  fails) to   instead of the default 3:

Requiring the root password instead of the user's password

Another interesting feature is to keep the  variable set so that you can execute graphical tools:

Keeping the DISPLAY variable alive

You can change dozens of default settings using the  directive. Fire up the  manual page and search for.

If you however want to allow a user to run a certain set of commands without providing any password whatsoever, you need to start the commands with , like so:

Allowing emerge to be ran as root without asking for a password

Listing Privileges
To inform yourself what your capabilities are, run  :

If you have any command in that does not require you to enter a password, it will not require a password to list the entries either. Otherwise you might be asked for your password if it isn't remembered.

Prolonging the Password Timeout
By default, if a user has entered his password to authenticate himself to , it is remembered for 5 minutes. If the user wants to prolong this period, he can run  to reset the time stamp so that it will take another 5 minutes before   asks for the password again.

The inverse is to kill the time stamp using.

Bash Completion
Users that want bash completion with sudo need to run this once.

Zshell Completion
User that want zsh completion for sudo can set the following in .zprofile and .zshrc respectively

.zprofile .zshrc With the above the path for commands in 'sbin' will be available to the shell and so completion activated when the command is prefaced with 'sudo'.