Differences between revisions 4 and 54 (spanning 50 versions)
Revision 4 as of 2008-12-11 18:28:58
Size: 3066
Editor: ?MartinAmmermüller
Comment: Added info about Debian default which took me lots of time to find out about.
Revision 54 as of 2021-11-29 11:19:32
Size: 8099
Comment: fixed translation header tags
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## Auto-converted by kwiki2moinmoin v2005-10-07
["root"]
#language en
##For Translators - to have a constantly up to date translation header in you page, you can just add a line like the following (with the comment's character at the start of the line removed)
## <<Include(sudo, ,from="^##TAG:TRANSLATION-HEADER-START",to="^##TAG:TRANSLATION-HEADER-END")>>
##TAG:TRANSLATION-HEADER-START
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[ar/sudo|العربية]] - [[sudo|English]] - [[es/sudo|Español]] - [[fr/sudo|Français]] - [[it/sudo|Italiano]] - [[ru/sudo|Русский]]-~
##TAG:TRANSLATION-HEADER-END
Line 4: Line 8:
Sudo is a program designed to allow a sysadmin to give limited ["root"] privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow people to get their work done. [[Root]] > sudo
----
~+Sudo+~ (sometimes considered as short for '''S'''uper-'''u'''ser '''do''') is a program designed to let system administrators allow some users to execute some commands as [[root]] (or another user). The basic philosophy is to give as few privileges as possible but still allow people to get their work done. Sudo is also an effective way to log who ran which command and when.
Line 6: Line 12:
 * DebPkg:sudo == Why sudo? ==
Using {{{sudo}}} is better (safer) than opening a session as root for a number of reasons, including:
 * Nobody needs to know the root password ({{{sudo}}} prompts for the current user's password). Extra privileges can be granted to individual users temporarily, and then taken away without the need for a password change.
 * It's easy to run only the commands that require special privileges via {{{sudo}}}; the rest of the time, you work as an unprivileged user, which reduces the damage that mistakes can cause.
 * Auditing/logging: when a sudo command is executed, the original username and the command are logged.
Line 8: Line 18:
== Example ==
{{{
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#
# Example from http://www.lea-linux.org/cached/index/Admin-admin_env-sudo.html
For the reasons above, ''switching'' to root using {{{sudo -i}}} (or {{{sudo su}}}) is usually deprecated because it cancels the above features.
Line 18: Line 20:
# User alias specification
# ------------------------
User_Alias PPPUSERS = fred, bibi, jice, serge
User_Alias HALTUSERS = fred, bibi
User_Alias ROOT_FRIENDS = jice, serge, fred
== Users and sudo ==
Line 24: Line 22:
# Host alias specification
# ------------------------
Host_Alias ICI = localhost, 192.168.1.1, ma.machine.fr
Host_Alias LABAS = www.tuxfamily.org, talk.revolink.com, 233.12.66.4
Host_Alias WWW = www*, mail*, pop*, *fr
Debian's default configuration allows users in the `sudo` group to run any command via `sudo`.
Line 30: Line 24:
# Runas alias specification
# -------------------------
Runsas_Alias USERPPP = pppuser, serialuser
=== Verifying sudo membership ===
Line 34: Line 26:
# Cmnd alias specification
# ------------------------
Cmnd_Alias STOPPC = /sbin/halt, /sbin/reboot, !/sbin/shutdown -*, /sbin/shutdown -r, \
                       /sbin/shutdown -h
Cmnd_Alias PPPCMD = /etc/ppp/scripts/pppconnect, /etc/ppp/scripts/pppdisconnect
Once logged in as a user, you can verify whether or not the user belongs to group=`sudo` using either the {{{id}}} or {{{groups}}} commands. E.g., a user with id=`foo` should see output from
Line 40: Line 28:
# User privilege specification
# ----------------------------
fred localhost = (ALL) ALL, (root) !ALL
PPPUSERS MONRESEAU = (USERPPP) NOPASSWD: /sbin/pppd, PPPCMD
john ALPHA = /usr/bin/su [!-]*, !/usr/bin/su *root*
+secretaires LOCALE = PRINTING_CMDS, /usr/sbin/adduser [A-z]*
 {{{#!plain
$ groups
Line 49: Line 32:
== Troubles and tweaks == like
Line 51: Line 34:
=== CVE-2005-4158 ===  {{{#!plain
foo sudo
}}}
Line 53: Line 38:
With the fix for CVE-2005-4158: Insecure handling of PERLLIB PERL5LIB PERL5OPT environment vars, the default behaviour of handling environment variables was switched to protect against malicious local users with sudo privileges getting sudo to do more than the malcontent was given privileges to do. If `sudo` is not present in the output, the user does not belong to that group. Similarly, the more complex and variable output from command=`id` should look something like
Line 55: Line 40:
 sudo (1.6.8p7-1.3) stable-security; urgency=high  {{{#!plain
uid=1001(foo) gid=1001(foo) groups=1001(foo),27(sudo)
}}}
Line 57: Line 44:
  * Non-maintainer upload by the Security Team
  * Reverse the environment semantic by forcing users to maintain a whitelist [env.c, Bug#342948, CVE-2005-4158]
==== Add existing user from commandline ====
Line 60: Line 46:
As a result, unless you modify your sudoers file to contain '''Defaults env_reset''', you may experiance problems using sudo like the following: To add an existing user with id=`foo` to group=`sudo`:
Line 62: Line 48:
 * E138: Can’t write viminfo file $HOME/.viminfo!
 * dircolors: no SHELL environment variable, and no shell type option given
 * squidview: can't get your home directory, exiting
 {{{#!plain
$ sudo adduser foo sudo
}}}
Line 66: Line 52:
If you had more complex setups where you meant to pass through environment variables, your work around may be more complex or no longer possible. Alternatively, you can first get root (e.g., `sudo su -`) and then run the same commands without prefix=`sudo`:
Line 68: Line 54:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342948  {{{#!plain
# adduser foo
# adduser foo sudo
}}}
Line 70: Line 59:
=== PASSWD option not working === After being added to a new group the user must log out and then log back in again for the new group to take effect. Groups are only assigned to users at login time. A most common source of confusion is that people add themselves to a new group but then do not log out and back in again and then have problems because the group is not assigned; be sure to [[#Verifying_sudo_membership|verify group membership]].
Line 72: Line 61:
sudo has a flag called '''exempt_group''' which contains a list of groups for which always NOPASSWD is true and setting PASSWD has no effect. On Debian Systems this list consists of the group '''sudo'''. === Creating users with sudo ===

You can also create new users with `sudo` membership:

==== Creating new user while installing OS ====

As of DebianSqueeze, if you give root an empty password during installation, {{{sudo}}} will be installed and the first user will be able to use it to gain root access (currently, the user will be added to the '''sudo''' group). The system will also configure {{{gksu}}} and {{{aptitude}}} to use {{{sudo}}}. You should still [[#Verifying_sudo_membership|verify group membership]] after logging in as the installed user.

==== Creating new user from commandline ====

A user which already has `sudo` can create another user (example id=`foo`) with `sudo` group membership from the commandline:

 {{{#!plain
$ sudo adduser foo -G sudo
}}}

(or first get root as in previous section).
You should then login as the new user and [[#Verifying_sudo_membership|verify group membership]].

== Configuration overview ==

Now, if you want to allow certain users to execute certain programs, here's a quick example (for more information, read the fine manual), which you can put in a file in /etc/sudoers.d, probably using visudo -f /etc/sudoers.d/myfile.

~-{{{#!plain
User_Alias MYADMINS = jdoe

Cmnd_Alias SHUTDOWN = /sbin/reboot, /sbin/poweroff
Cmnd_Alias PKGMGMT = /usr/bin/dpkg, /usr/bin/apt-get, /usr/bin/aptitude

# Users listed above (MYADMINS) can run package managers and reboot the system.
MYADMINS ALL = PKGMGMT, SHUTDOWN
}}}-~

== Problems and tips ==

=== Sorry, user jdoe is not allowed to execute ... ===
A typical session goes like this:
 {{{#!plain
$ sudo test

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.

[sudo] password for jdoe:
Sorry, user jdoe is not allowed to execute '/usr/bin/test' as root on localhost.
}}}

This message means what it says: the user you're running as isn't allowed to execute the given command on the given machine. One confusing possible reason for this is that the administrator has just added user jdoe to a privileged group - but you're still using the old login, which doesn't have that new group information, and therefore has no new sudo-ing rights. People in this situation are usually advised to log out completely and back in again, though you can sometimes get away with just performing a "re-login on the spot" with {{{su - $USER}}} or changing group with {{{newgrp sudo}}}.

=== The include directive ===

The standard {{{/etc/sudoers}}} ends with a line:

 {{{#!plain
 #includedir /etc/sudoers.d
}}}

This makes it possible for other packages to provide snippets in {{{/etc/sudoers.d/<packagename>}}} which modify the configuration of {{{sudo}}}. It may look as if it needs to be edited to take out the leading numbersign (a.k.a. "hash" or "pound"), but no, the '#' is part of the directive!

It is recommended that you make local changes in a snippet as well.

=== sudoers is read-only ===

Yes, the file {{{/etc/sudoers}}} is intentionally set read-only, even for root!

The explanation is that it was set up this way to motivate admins to only ever edit it via the command {{{visudo,}}} which provides additional checking before leaving the new file in place. You might think that the fix for a mangled {{{/etc/sudoers}}}, the fix may be as simple as {{{su -c visudo}}}, but sudo is often used in a place where simply {{{su}}}'ing to root is not possible since you simply don't know the root password.

Beware, most text editors will let you edit the file without complaining about the read-only bit, so you might not automatically get this additional protection.

=== Require root password ===

If you want to require the root password for use of sudo, rather than the user password, add the line:

~-{{{#!plain
Defaults rootpw
}}}-~

=== No password prompt for sudo user ===

If you want sudo group members to execute commands without password, add the line:

~-{{{#!plain
%sudo ALL=(ALL) NOPASSWD: ALL
}}}-~

=== Customize credentials cache timeout ===

As default, after asking a password, your credentials are cached by `sudo` and last for 15 minutes. You can change this behavior using the command {{{visudo}}} and customizing the timeout for a specific user:

~-{{{#!plain
Defaults:foobar timestamp_timeout=30
}}}-~

== See also ==
 * Manpages: [[DebianMan:5/sudoers|sudoers(5)]], [[DebianMan:8/sudo|sudo(8)]], [[DebianMan:8/visudo|visudo(8)]], [[DebianMan:8/sudoedit|sudoedit(8)]], [[DebianMan:8/sudoreplay|sudoreplay(8)]]
 * [[Doas]] - A lighter and more minimalistic tool for the same purpose, with simpler configuration.

----

CategoryRoot | CategorySystemSecurity | CategorySystemAdministration

Translation(s): العربية - English - Español - Français - Italiano - Русский


Root > sudo


Sudo (sometimes considered as short for Super-user do) is a program designed to let system administrators allow some users to execute some commands as root (or another user). The basic philosophy is to give as few privileges as possible but still allow people to get their work done. Sudo is also an effective way to log who ran which command and when.

Why sudo?

Using sudo is better (safer) than opening a session as root for a number of reasons, including:

  • Nobody needs to know the root password (sudo prompts for the current user's password). Extra privileges can be granted to individual users temporarily, and then taken away without the need for a password change.

  • It's easy to run only the commands that require special privileges via sudo; the rest of the time, you work as an unprivileged user, which reduces the damage that mistakes can cause.

  • Auditing/logging: when a sudo command is executed, the original username and the command are logged.

For the reasons above, switching to root using sudo -i (or sudo su) is usually deprecated because it cancels the above features.

Users and sudo

Debian's default configuration allows users in the sudo group to run any command via sudo.

Verifying sudo membership

Once logged in as a user, you can verify whether or not the user belongs to group=sudo using either the id or groups commands. E.g., a user with id=foo should see output from

  • $ groups

like

  • foo sudo

If sudo is not present in the output, the user does not belong to that group. Similarly, the more complex and variable output from command=id should look something like

  • uid=1001(foo) gid=1001(foo) groups=1001(foo),27(sudo)

Add existing user from commandline

To add an existing user with id=foo to group=sudo:

  • $ sudo adduser foo sudo

Alternatively, you can first get root (e.g., sudo su -) and then run the same commands without prefix=sudo:

  • # adduser foo
    # adduser foo sudo

After being added to a new group the user must log out and then log back in again for the new group to take effect. Groups are only assigned to users at login time. A most common source of confusion is that people add themselves to a new group but then do not log out and back in again and then have problems because the group is not assigned; be sure to verify group membership.

Creating users with sudo

You can also create new users with sudo membership:

Creating new user while installing OS

As of DebianSqueeze, if you give root an empty password during installation, sudo will be installed and the first user will be able to use it to gain root access (currently, the user will be added to the sudo group). The system will also configure gksu and aptitude to use sudo. You should still verify group membership after logging in as the installed user.

Creating new user from commandline

A user which already has sudo can create another user (example id=foo) with sudo group membership from the commandline:

  • $ sudo adduser foo -G sudo

(or first get root as in previous section). You should then login as the new user and verify group membership.

Configuration overview

Now, if you want to allow certain users to execute certain programs, here's a quick example (for more information, read the fine manual), which you can put in a file in /etc/sudoers.d, probably using visudo -f /etc/sudoers.d/myfile.

User_Alias      MYADMINS = jdoe

Cmnd_Alias      SHUTDOWN = /sbin/reboot, /sbin/poweroff
Cmnd_Alias      PKGMGMT = /usr/bin/dpkg, /usr/bin/apt-get, /usr/bin/aptitude

# Users listed above (MYADMINS) can run package managers and reboot the system.
MYADMINS ALL = PKGMGMT, SHUTDOWN

Problems and tips

Sorry, user jdoe is not allowed to execute ...

A typical session goes like this:

  • $ sudo test
    
    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.
    
    [sudo] password for jdoe: 
    Sorry, user jdoe is not allowed to execute '/usr/bin/test' as root on localhost.

This message means what it says: the user you're running as isn't allowed to execute the given command on the given machine. One confusing possible reason for this is that the administrator has just added user jdoe to a privileged group - but you're still using the old login, which doesn't have that new group information, and therefore has no new sudo-ing rights. People in this situation are usually advised to log out completely and back in again, though you can sometimes get away with just performing a "re-login on the spot" with su - $USER or changing group with newgrp sudo.

The include directive

The standard /etc/sudoers ends with a line:

  •  #includedir /etc/sudoers.d

This makes it possible for other packages to provide snippets in /etc/sudoers.d/<packagename> which modify the configuration of sudo. It may look as if it needs to be edited to take out the leading numbersign (a.k.a. "hash" or "pound"), but no, the '#' is part of the directive!

It is recommended that you make local changes in a snippet as well.

sudoers is read-only

Yes, the file /etc/sudoers is intentionally set read-only, even for root!

The explanation is that it was set up this way to motivate admins to only ever edit it via the command visudo, which provides additional checking before leaving the new file in place. You might think that the fix for a mangled /etc/sudoers, the fix may be as simple as su -c visudo, but sudo is often used in a place where simply su'ing to root is not possible since you simply don't know the root password.

Beware, most text editors will let you edit the file without complaining about the read-only bit, so you might not automatically get this additional protection.

Require root password

If you want to require the root password for use of sudo, rather than the user password, add the line:

Defaults   rootpw

No password prompt for sudo user

If you want sudo group members to execute commands without password, add the line:

%sudo ALL=(ALL) NOPASSWD: ALL

Customize credentials cache timeout

As default, after asking a password, your credentials are cached by sudo and last for 15 minutes. You can change this behavior using the command visudo and customizing the timeout for a specific user:

Defaults:foobar timestamp_timeout=30

See also


CategoryRoot | CategorySystemSecurity | CategorySystemAdministration