| 1 |
swift 05/08/02 16:14:21 |
| 2 |
|
| 3 |
Added: xml/htdocs/doc/en/draft sudo-guide.xml |
| 4 |
Log: |
| 5 |
Sudo guide, draft |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/doc/en/draft/sudo-guide.xml |
| 9 |
|
| 10 |
file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/sudo-guide.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo |
| 11 |
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/sudo-guide.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo |
| 12 |
|
| 13 |
Index: sudo-guide.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version='1.0' encoding="UTF-8"?> |
| 16 |
|
| 17 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/sudo-guide.xml,v 1.1 2005/08/02 16:14:21 swift Exp $ --> |
| 18 |
|
| 19 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 20 |
|
| 21 |
<guide link="/doc/en/sudo-guide.xml"> |
| 22 |
<title>Gentoo Sudo(ers) Guide</title> |
| 23 |
|
| 24 |
<author title="Author"> |
| 25 |
<mail link="swift@g.o">Sven Vermeulen</mail> |
| 26 |
</author> |
| 27 |
|
| 28 |
<abstract> |
| 29 |
When you want some people to perform certain administrative steps on your |
| 30 |
system without granting them total root access, using sudo is your best option. |
| 31 |
With sudo you can control who can do what. This guide offers you a small |
| 32 |
introduction to this wonderful tool. |
| 33 |
</abstract> |
| 34 |
|
| 35 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 36 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 37 |
<license/> |
| 38 |
|
| 39 |
<version>0.1</version> |
| 40 |
<date>2005-01-01</date> |
| 41 |
|
| 42 |
<chapter> |
| 43 |
<title>About Sudo</title> |
| 44 |
<section> |
| 45 |
<title>Granting Permissions</title> |
| 46 |
<body> |
| 47 |
|
| 48 |
<p> |
| 49 |
The <c>app-admin/sudo</c> package allows the system administrator to grant |
| 50 |
permission to other users to execute one or more applications they would |
| 51 |
normally have no access to. Unlike using the <e>setuid</e> bit on these |
| 52 |
applications <c>sudo</c> gives a more fine-grained control on <e>who</e> can |
| 53 |
execute a certain command and <e>when</e>. |
| 54 |
</p> |
| 55 |
|
| 56 |
<p> |
| 57 |
With <c>sudo</c> you can make a clear list <e>who</e> can execute a certain |
| 58 |
application. If you would set the setuid bit, any user would be able to run this |
| 59 |
application (or any user of a certain group, depending on the permissions used). |
| 60 |
You can (and probably even should) require the user to provide a password when |
| 61 |
he wants to execute the application and you can even fine-tune the permissions |
| 62 |
based on the location where the user is at: if he is logged on from the system |
| 63 |
itself or through SSH from a remote site. |
| 64 |
</p> |
| 65 |
|
| 66 |
</body> |
| 67 |
</section> |
| 68 |
<section> |
| 69 |
<title>Logging Activity</title> |
| 70 |
<body> |
| 71 |
|
| 72 |
<p> |
| 73 |
One additional advantage of <c>sudo</c> is that it can log any attempt |
| 74 |
(succesful or not) to run an application. This is very useful if you want to |
| 75 |
track who made that one fatal mistake that took you 10 hours to fix :) |
| 76 |
</p> |
| 77 |
|
| 78 |
</body> |
| 79 |
</section> |
| 80 |
<section> |
| 81 |
<title>Configuring Sudo</title> |
| 82 |
<body> |
| 83 |
|
| 84 |
<p> |
| 85 |
The <c>sudo</c> configuration is managed by the <path>/etc/sudoers</path> file. |
| 86 |
This file should never be edited through <c>nano /etc/sudoers</c> or |
| 87 |
<c>vim /etc/sudoers</c> or any other editor you might like. When you want |
| 88 |
to alter this file, you should use <c>visudo</c>. |
| 89 |
</p> |
| 90 |
|
| 91 |
<p> |
| 92 |
This tool makes sure that no two system administrators are editing this file at |
| 93 |
the same time, preserves the permissions on the file and performs some syntax |
| 94 |
checking to make sure you make no fatal mistakes in the file. |
| 95 |
</p> |
| 96 |
|
| 97 |
</body> |
| 98 |
</section> |
| 99 |
<section> |
| 100 |
<title>About this Guide</title> |
| 101 |
<body> |
| 102 |
|
| 103 |
<p> |
| 104 |
This guide is meant as a quick introduction. The <c>sudo</c> package is a lot |
| 105 |
more powerful than what is described in this guide. It has special features for |
| 106 |
editing files as a different user (<c>sudoedit</c>), running from within a |
| 107 |
script (so it can background, read the password from standard in instead of the |
| 108 |
keyboard, ...), etc. |
| 109 |
</p> |
| 110 |
|
| 111 |
</body> |
| 112 |
</section> |
| 113 |
</chapter> |
| 114 |
|
| 115 |
<chapter> |
| 116 |
<title>Sudoers Syntax</title> |
| 117 |
<section> |
| 118 |
<title>Basic Syntax</title> |
| 119 |
<body> |
| 120 |
|
| 121 |
<p> |
| 122 |
The most difficult part of <c>sudo</c> is the <path>/etc/sudoers</path> syntax. |
| 123 |
The basic syntax is like so: |
| 124 |
</p> |
| 125 |
|
| 126 |
<pre caption="Basic /etc/sudoers syntax"> |
| 127 |
user host = commands |
| 128 |
</pre> |
| 129 |
|
| 130 |
<p> |
| 131 |
This syntax tells <c>sudo</c> that the user, identified by <e>user</e> and |
| 132 |
logged on through the system <e>host</e> can execute any of the commands listed |
| 133 |
in <e>commands</e> as the root user. A more real-life example might make this |
| 134 |
more clear: allow the user <e>swift</e> to execute <c>emerge</c> if he is logged |
| 135 |
on from the system (not through SSH): |
| 136 |
</p> |
| 137 |
|
| 138 |
<pre caption="Live /etc/sudoers examples"> |
| 139 |
swift localhost = /usr/bin/emerge |
| 140 |
</pre> |
| 141 |
|
| 142 |
<p> |
| 143 |
You can extend the line to allow for several commands (instead of making a |
| 144 |
single entry for each command). For instance, to allow the same user to not only |
| 145 |
run <c>emerge</c> but also <c>ebuild</c> and <c>emerge-webrsync</c> as root: |
| 146 |
</p> |
| 147 |
|
| 148 |
<pre caption="Multiple commands"> |
| 149 |
swift localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync |
| 150 |
</pre> |
| 151 |
|
| 152 |
<p> |
| 153 |
You can also specify a precise command and not only the tool itself. This is |
| 154 |
useful to restrict the use of a certain tool to a specified set of command |
| 155 |
options. The <c>sudo</c> tool allows for regular expressions to be used as well. |
| 156 |
</p> |
| 157 |
|
| 158 |
<p> |
| 159 |
Let us put this to the test: |
| 160 |
</p> |
| 161 |
|
| 162 |
<pre caption="Attempt to update the system using sudo"> |
| 163 |
$ <i>sudo emerge -uDN world</i> |
| 164 |
|
| 165 |
We trust you have received the usual lecture from the local System |
| 166 |
Administrator. It usually boils down to these three things: |
| 167 |
|
| 168 |
#1) Respect the privacy of others. |
| 169 |
#2) Think before you type. |
| 170 |
#3) With great power comes great responsibility. |
| 171 |
|
| 172 |
Password: <comment>(Enter the user password, not root!)</comment> |
| 173 |
</pre> |
| 174 |
|
| 175 |
<p> |
| 176 |
The password that <c>sudo</c> requires is the user his own password. This is to |
| 177 |
make sure that no terminal that you accidentally left open to others is abused |
| 178 |
for malicious purposes. |
| 179 |
</p> |
| 180 |
|
| 181 |
<p> |
| 182 |
You should know that <c>sudo</c> does not alter the <c>${PATH}</c> variable: any |
| 183 |
command you place after <c>sudo</c> is treated from <e>your</e> environment. If |
| 184 |
you want the user to run a tool in for instance <path>/sbin</path> he should |
| 185 |
provide the full path to <c>sudo</c>, like so: |
| 186 |
</p> |
| 187 |
|
| 188 |
<pre caption="Using the full path to a tool"> |
| 189 |
$ <i>sudo /usr/sbin/emerge-webrsync</i> |
| 190 |
</pre> |
| 191 |
|
| 192 |
</body> |
| 193 |
</section> |
| 194 |
<section> |
| 195 |
<title>Using Aliases</title> |
| 196 |
<body> |
| 197 |
|
| 198 |
<p> |
| 199 |
In larger environments having to enter all users over and over again (or hosts, |
| 200 |
or commands) can be a daunting task. To ease the administration of |
| 201 |
<path>/etc/sudoers</path> you can define <e>aliases</e>. The format to declare |
| 202 |
aliases is quite simple: |
| 203 |
</p> |
| 204 |
|
| 205 |
<pre caption="Declaring aliases in /etc/sudoers"> |
| 206 |
Host_Alias hostalias = hostname1, hostname2, ... |
| 207 |
User_Alias useralias = user1, user2, ... |
| 208 |
Cmnd_Alias cmndalias = command1, command2, ... |
| 209 |
</pre> |
| 210 |
|
| 211 |
<p> |
| 212 |
One alias that always works, for any position, is the <c>ALL</c> alias (to make |
| 213 |
a good distinction between aliases and non-aliases it is recommended to use |
| 214 |
|
| 215 |
|
| 216 |
|
| 217 |
-- |
| 218 |
gentoo-doc-cvs@g.o mailing list |
Archives