Important: You are required to change your passwords used for Gentoo services and set an email address for your Wiki account if you haven't done so. See the full announcement and Wiki email policy change for more information.

sudo

From Gentoo Wiki
Jump to: navigation, search
Other languages:English 100% • ‎español 100% • ‎français 100% • ‎한국어 4% • ‎русский 100%

External resources

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.

About Sudo

Granting Permissions

The app-admin/sudo 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 sudo gives a more fine-grained control on who can execute a certain command and when .

With sudo 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.

Emerge Sudo

→ Information about USE flags
USE flag Default Recommended Description
ldap No Adds LDAP support (Lightweight Directory Access Protocol)
nls No Adds Native Language Support (using gettext - GNU locale utilities)
pam No Yes Adds support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip
offensive No Let sudo print insults when the user types the wrong password.
skey No Enable S/Key (Single use password) authentication support
selinux No  !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
sendmail No Allow sudo to send emails with sendmail.
root # emerge --ask sudo


Logging Activity

One additional advantage of sudo 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 sudo configuration is managed by the /etc/sudoers file. This file should never be edited through nano /etc/sudoers or vim /etc/sudoers or any other editor you might like. When you want to alter this file, you should use visudo .

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 sudo package is a lot more powerful than what is described in this guide. It has special features for editing files as a different user ( sudoedit ), running from within a script (so it can background, read the password from standard in instead of the keyboard, ...), etc.

Please read the sudo and sudoers manual pages for more information.

Sudoers Syntax

Basic Syntax

The most difficult part of sudo is the /etc/sudoers syntax. The basic syntax is like so:

CodeBasic /etc/sudoers syntax

user  host = commands

This syntax tells sudo 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 emerge if he is logged in on localhost:

CodeLive /etc/sudoers examples

swift  localhost = /usr/bin/emerge
Note
The hostname must match what the hostname command returns.
Warning
Do not allow a user to run an application that can allow people to elevate privileges. For instance, allowing users to execute emerge as root can indeed grant them full root access to the system because emerge can be manipulated to change the live file system to the user's advantage. If you do not trust your sudo 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 wheel group to execute emerge :

CodeAllowing the wheel group members to execute emerge

%wheel  localhost = /usr/bin/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 emerge but also ebuild and emerge-webrsync as root:

CodeMultiple commands

swift  localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync

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 sudo 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:

user $ sudo emerge -uDN world
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
  
    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.
  
Password: ## (Enter the user password, not root!)

The password that sudo 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 sudo does not alter the ${PATH} variable: any command you place after sudo is treated from your environment. If you want the user to run a tool in for instance /sbin he should provide the full path to sudo , like so:

user $ sudo /usr/sbin/emerge-webrsync

Basic Syntax with LDAP

The following use flag is needed for the LDAP support.

→ Information about USE flags
USE flag Default Recommended Description
ldap No Yes Adds LDAP support (Lightweight Directory Access Protocol)
pam No Yes Adds support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip

When using sudo with LDAP, sudo will read configuration from LDAP Server as well. So you will need to edit two files.

File/etc/ldap.conf.sudoPlease chmod 400 when done

# See ldap.conf(5) and README.LDAP for details
# This file should only be readable by root
  
# supported directives: host, port, ssl, ldap_version
# uri, binddn, bindpw, sudoers_base, sudoers_debug
# tls_{checkpeer,cacertfile,cacertdir,randfile,ciphers,cert,key
  
host ldap.example.com
port 389
  
base dc=example,dc=com
  
uri ldap://ldap.example.com/
#uri ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock
  
ldap_version 3
#ssl start_tls
  
sudoers_base ou=SUDOers,dc=example,dc=com
#sudoers_debug 2
  
bind_policy soft
File/etc/nsswitch.confPlease add the sudoers line

sudoers:     ldap files

Also you will need to add in the following LDAP Entry for Sudo.

Note
It was design so that the Sudoers branch are on top of the tree for security reason. So you can have a different access right from ldap to read/write to this branch
CodeLdap Entry for Sudo

version: 1
DN: ou=SUDOers,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
objectClass: domainRelatedObject
associatedDomain: example.com
ou: SUDOers
  
DN: cn=defaults,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
sudoOption: env_reset
  
DN: cn=root,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: root
sudoCommand: ALL
sudoHost: ALL
sudoUser: root
  
DN: cn=%wheel,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: %wheel
sudoCommand: ALL
sudoHost: ALL
sudoOption: !authenticate
sudoUser: %wheel


CodeLdap Entry for wheel Group

version: 1
DN: cn=wheel,ou=Group,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: wheel
description: Wheel Group
gidNumber: 10
memberUid: useradmin1
memberUid: root

The configuration on the sudoer on LDAP are similar to files with some different. Please read more about Sudo with LDAP on the link below.[1]

  1. [1]Sudoers LDAP man Page

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 /etc/sudoers you can define aliases . The format to declare aliases is quite simple:

CodeDeclaring aliases in /etc/sudoers

Host_Alias hostalias = hostname1, hostname2, ...
User_Alias useralias = user1, user2, ...
Cmnd_Alias cmndalias = command1, command2, ...

One alias that always works, for any position, is the ALL 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 ALL alias is an alias to all possible settings.

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

CodeAllowing any user to execute shutdown

ALL  localhost = /sbin/shutdown

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

CodeAllowing a user to run an application regardless of his location

swift   ALL = /usr/bin/emerge

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

CodeUsing aliases for users and commands

User_Alias  SOFTWAREMAINTAINERS = swift, john, danny
User_Alias  PASSWORDMAINTAINERS = swift, sysop
Cmnd_Alias  SOFTWARECOMMANDS    = /usr/bin/emerge, /usr/bin/ebuild
Cmnd_Alias  PASSWORDCOMMANDS    = /usr/bin/passwd [a-zA-Z0-9_-]*, !/usr/bin/passwd root
  
SOFTWAREMAINTAINERS  localhost = SOFTWARECOMMANDS
PASSWORDMAINTAINERS  localhost = PASSWORDCOMMANDS

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 apache for the web server) and want to allow certain users to perform administrative steps as that user (like killing zombie processes).

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

CodeNon-root execution syntax

users  hosts = (run-as) commands

For instance, to allow swift to run the kill tool as the apache or gorg user:

CodeNon-root execution example

Cmnd_Alias KILL = /bin/kill, /usr/bin/pkill
  
swift   ALL = (apache, gorg) KILL

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

user $ sudo -u apache pkill apache

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

Passwords and Default Settings

By default, sudo asks the user to identify himself using his own password. Once a password is entered, sudo 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 Defaults: directive in /etc/sudoers to change the default behavior for a user.

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

CodeChanging the timeout value

Defaults:swift  timestamp_timeout=0

A setting of -1 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 runaspw . In the following example we also set the number of retries (how many times the user can re-enter a password before sudo fails) to 2 instead of the default 3:

CodeRequiring the root password instead of the user's password

Defaults:john   runaspw, passwd_tries=2

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

CodeKeeping the DISPLAY variable alive

Defaults:john env_keep=DISPLAY

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

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 NOPASSWD: , like so:

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

swift     localhost = NOPASSWD: /usr/bin/emerge

Using Sudo

Listing Privileges

To inform yourself what your capabilities are, run sudo -l :

user $ sudo -l
User swift may run the following commands on this host:
    (root)   /usr/libexec/xfsm-shutdown-helper
    (root)   /usr/bin/emerge
    (root)   /usr/bin/passwd [a-zA-Z0-9_-]*
    (root)   !/usr/bin/passwd root
    (apache) /usr/bin/pkill
    (apache) /bin/kill

If you have any command in /etc/sudoers 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 sudo , it is remembered for 5 minutes. If the user wants to prolong this period, he can run sudo -v to reset the time stamp so that it will take another 5 minutes before sudo asks for the password again.

user $ sudo -v

The inverse is to kill the time stamp using sudo -k .

Sudo enhancements

Bash Completion

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

user $ sudo echo "complete -cf sudo" >> $HOME/.bashrc

Zshell Completion

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

File.zprofileAdding zshell completion

if [[ $EUID != 0 ]]; then
    typeset -xT SUDO_PATH sudo_path
    typeset -U sudo_path 
    sudo_path=({,/usr/local,/usr}/sbin(N-/))
    alias sudo="sudo env PATH=\"SUDO_PATH:$PATH\""
fi
File.zshrcAdding zshell completion

zstyle ':completion:*:sudo:*' environ PATH="$SUDO_PATH:$PATH"

With the above change, all commands in the /sbin, /usr/sbin and /usr/local/sbin locations will be available to the shell for completion when the command is prefaced with 'sudo'.