2822
Comment: adding one example
|
7900
make it clear that foo is to be replaced in the adduser example
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
## Auto-converted by kwiki2moinmoin v2005-10-07 ["root"] |
#language en ##TRANSLATION-HEADER-START ~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[ar/sudo|العربية]] - English - [[es/sudo|Español]] - [[fr/sudo|Français]] - [[it/sudo|Italiano]] - [[ru/sudo|Русский]]-~ ##TRANSLATION-HEADER-END |
Line 4: | Line 6: |
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 10: |
* DebPkg:sudo | As of DebianSqueeze, if you ask for the Desktop task during the installation, that pulls in {{{sudo}}} with a default configuration that automatically grants sudo-ing rights to any member of the '''sudo''' group. Depending on what user accounts you set up during the install, it's still possible that you may not have been added to that group - you can check by running {{{groups}}}. |
Line 8: | Line 12: |
== Example == {{{ |
To add the user `foo` to the sudo group: {{{#!plain # 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. You can check what groups you are in with the {{{id}}} or {{{groups}}} commands. == 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. == 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). ~-{{{#!plain |
Line 16: | Line 37: |
# Example from http://www.lea-linux.org/cached/index/Admin-admin_env-sudo.html | Defaults env_reset Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" # Host alias specification User_Alias MYADMINS = jdoe |
Line 19: | Line 45: |
# ------------------------ User_Alias PPPUSERS = fred, bibi, jice, serge User_Alias HALTUSERS = fred, bibi User_Alias ROOT_FRIENDS = jice, serge, fred # 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 # Runas alias specification # ------------------------- Runsas_Alias USERPPP = pppuser, serialuser |
|
Line 35: | Line 47: |
# ------------------------ 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 |
Cmnd_Alias SHUTDOWN = /sbin/shutdown, /sbin/reboot, /sbin/halt Cmnd_Alias PKGMGMT = /usr/bin/dpkg, /usr/bin/apt-get, /usr/bin/aptitude |
Line 41: | Line 51: |
# ---------------------------- 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]* |
|
Line 47: | Line 52: |
# Users listed above (MYADMINS) can run package managers and reboot the system. MYADMINS ALL = PKGMGMT, SHUTDOWN # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL #Default rule for root. root ALL=(ALL) ALL #includedir /etc/sudoers.d }}}-~ == Problems and tips == === PATH not set === A typical error using sudo to install a package might result in: {{{ dpkg: warning: 'ldconfig' not found in PATH or not executable. dpkg: warning: 'start-stop-daemon' not found in PATH or not executable. dpkg: error: 2 expected programs not found in PATH or not executable. Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin. |
|
Line 49: | Line 77: |
== Troubles and tweaks == | The packaged /etc/sudoers file contains this line: |
Line 51: | Line 79: |
=== CVE-2005-4158 === | {{{ Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" }}} |
Line 53: | Line 83: |
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. | Previous versions did not include that line. If you had a locally modified /etc/sudoers (most would) and then upgraded and kept your locally modified version then this required line is now missing. It no longer overrides your PATH when using sudo. This most likely results in PATH not being set properly and not including the system directories. The fix is to merge your local changes into the new package /etc/sudoers file. Or to put your local changes in the new /etc/sudoers.d/ location as a uniquely named file such as {{{/etc/sudoers.d/local-sudoers}}}. See DebianBug:639841 for details. |
Line 55: | Line 85: |
sudo (1.6.8p7-1.3) stable-security; urgency=high | === Sorry, user jdoe is not allowed to execute ... === A typical session goes like this: {{{#!plain $ sudo test |
Line 57: | Line 90: |
* 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] |
We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: |
Line 60: | Line 93: |
As a result, unless you modify your sudoers file to contain '''Defaults env_reset''', you may experiance problems using sudo like the following: | #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. |
Line 62: | Line 97: |
* 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 |
[sudo] password for jdoe: Sorry, user jdoe is not allowed to execute '/usr/bin/test' as root on localhost. }}} |
Line 66: | Line 101: |
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. | 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}}} |
Line 68: | Line 103: |
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342948 | === The include directive === The standard {{{/etc/sudoers}}} in Wheezy as of 1.8.2-1 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! === sudoers is read-only === Yes, the file {{{/etc/sudoers}}} is intentionally set read-only, even for root! The explanation usually offered is that it was set up this way to ensure that admins only ever edit it via the command {{{visudo}}}. However, this theory doesn't quite hold water. Being mode 0440 does nothing to impede {{{sudo nano /etc/sudoers}}} - most text editors will let you edit the file without complaining about the read-only bit. Besides, any time you do mangle {{{/etc/sudoers}}}, the fix may be as simple as {{{su -c visudo}}}, which is nothing compared to the kind of recovery procedure you'd have to go through if you broke something like {{{/etc/inittab}}} (mode 0644). So if there's a good reason for the unorthodox permissions, it's a mystery - contributions welcome. === Wrong HOME (and profile settings) behavior === If you are having problems when you {{{sudo}}} to your shell and your $HOME (and profile settings) doesn't work as expected because your new HOME is /root, you need to know that the default {{{sudo}}} configuration in Squeeze resets all environmental variables. To restore the old behavior of preserving the user's $HOME environment variable you can add this to your {{{/etc/sudoers}}} configuration file: ~-{{{#!plain Defaults env_keep += HOME }}}-~ === 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 }}}-~ For more information read the [[http://www.sudo.ws/sudo/stable.html#1.7.4|upstream changelog for version 1.7.4]]. == 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)]] |
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.
As of DebianSqueeze, if you ask for the Desktop task during the installation, that pulls in sudo with a default configuration that automatically grants sudo-ing rights to any member of the sudo group. Depending on what user accounts you set up during the install, it's still possible that you may not have been added to that group - you can check by running groups.
To add the user foo to the sudo group:
# 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. You can check what groups you are in with the id or groups commands.
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.
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).
# /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.
#
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
# Host alias specification
User_Alias MYADMINS = jdoe
# User alias specification
# Cmnd alias specification
Cmnd_Alias SHUTDOWN = /sbin/shutdown, /sbin/reboot, /sbin/halt
Cmnd_Alias PKGMGMT = /usr/bin/dpkg, /usr/bin/apt-get, /usr/bin/aptitude
# User privilege specification
# Users listed above (MYADMINS) can run package managers and reboot the system.
MYADMINS ALL = PKGMGMT, SHUTDOWN
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
#Default rule for root.
root ALL=(ALL) ALL
#includedir /etc/sudoers.d
Problems and tips
PATH not set
A typical error using sudo to install a package might result in:
dpkg: warning: 'ldconfig' not found in PATH or not executable. dpkg: warning: 'start-stop-daemon' not found in PATH or not executable. dpkg: error: 2 expected programs not found in PATH or not executable. Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin.
The packaged /etc/sudoers file contains this line:
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Previous versions did not include that line. If you had a locally modified /etc/sudoers (most would) and then upgraded and kept your locally modified version then this required line is now missing. It no longer overrides your PATH when using sudo. This most likely results in PATH not being set properly and not including the system directories. The fix is to merge your local changes into the new package /etc/sudoers file. Or to put your local changes in the new /etc/sudoers.d/ location as a uniquely named file such as /etc/sudoers.d/local-sudoers. See 639841 for details.
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
The include directive
The standard /etc/sudoers in Wheezy as of 1.8.2-1 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!
sudoers is read-only
Yes, the file /etc/sudoers is intentionally set read-only, even for root!
The explanation usually offered is that it was set up this way to ensure that admins only ever edit it via the command visudo. However, this theory doesn't quite hold water. Being mode 0440 does nothing to impede sudo nano /etc/sudoers - most text editors will let you edit the file without complaining about the read-only bit. Besides, any time you do mangle /etc/sudoers, the fix may be as simple as su -c visudo, which is nothing compared to the kind of recovery procedure you'd have to go through if you broke something like /etc/inittab (mode 0644). So if there's a good reason for the unorthodox permissions, it's a mystery - contributions welcome.
Wrong HOME (and profile settings) behavior
If you are having problems when you sudo to your shell and your $HOME (and profile settings) doesn't work as expected because your new HOME is /root, you need to know that the default sudo configuration in Squeeze resets all environmental variables. To restore the old behavior of preserving the user's $HOME environment variable you can add this to your /etc/sudoers configuration file:
Defaults env_keep += HOME
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
For more information read the upstream changelog for version 1.7.4.
See also
Manpages: sudoers(5), sudo(8), visudo(8), sudoedit(8), sudoreplay(8)