/[gentoo]/xml/htdocs/doc/en/sudo-guide.xml
Gentoo

Contents of /xml/htdocs/doc/en/sudo-guide.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.13 - (hide annotations) (download) (as text)
Sun Aug 14 17:58:50 2011 UTC (3 years, 1 month ago) by swift
Branch: MAIN
Changes since 1.12: +10 -8 lines
File MIME type: application/xml
Sudoers does not care frmo where you are logged on. The hostname field is for the system on which the command is executed. Thanks to Chris X Edwards (chris xed ch) for reporting

1 swift 1.1 <?xml version='1.0' encoding="UTF-8"?>
2    
3 swift 1.13 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/sudo-guide.xml,v 1.12 2008/05/19 20:45:27 swift Exp $ -->
4 swift 1.1
5     <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
6    
7     <guide link="/doc/en/sudo-guide.xml">
8     <title>Gentoo Sudo(ers) Guide</title>
9    
10     <author title="Author">
11 nightmorph 1.11 <mail link="swift@gentoo.org">Sven Vermeulen</mail>
12 swift 1.1 </author>
13    
14     <abstract>
15 swift 1.12 When you want some people to perform certain administrative steps on your
16 swift 1.1 system without granting them total root access, using sudo is your best option.
17     With sudo you can control who can do what. This guide offers you a small
18     introduction to this wonderful tool.
19     </abstract>
20    
21     <!-- The content of this document is licensed under the CC-BY-SA license -->
22     <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
23     <license/>
24    
25 swift 1.13 <version>2</version>
26     <date>2011-08-13</date>
27 swift 1.1
28     <chapter>
29     <title>About Sudo</title>
30     <section>
31     <title>Granting Permissions</title>
32     <body>
33    
34     <p>
35     The <c>app-admin/sudo</c> package allows the system administrator to grant
36     permission to other users to execute one or more applications they would
37     normally have no right to. Unlike using the <e>setuid</e> bit on these
38     applications <c>sudo</c> gives a more fine-grained control on <e>who</e> can
39     execute a certain command and <e>when</e>.
40     </p>
41    
42     <p>
43     With <c>sudo</c> you can make a clear list <e>who</e> can execute a certain
44     application. If you would set the setuid bit, any user would be able to run this
45     application (or any user of a certain group, depending on the permissions used).
46     You can (and probably even should) require the user to provide a password when
47 swift 1.13 he wants to execute the application.
48 swift 1.1 </p>
49    
50     </body>
51     </section>
52     <section>
53     <title>Logging Activity</title>
54     <body>
55    
56     <p>
57     One additional advantage of <c>sudo</c> is that it can log any attempt
58     (successful or not) to run an application. This is very useful if you want to
59     track who made that one fatal mistake that took you 10 hours to fix :)
60     </p>
61    
62     </body>
63     </section>
64     <section>
65     <title>Configuring Sudo</title>
66     <body>
67    
68     <p>
69     The <c>sudo</c> configuration is managed by the <path>/etc/sudoers</path> file.
70     This file should never be edited through <c>nano&nbsp;/etc/sudoers</c> or
71     <c>vim&nbsp;/etc/sudoers</c> or any other editor you might like. When you want
72 swift 1.12 to alter this file, you should use <c>visudo</c>.
73 swift 1.1 </p>
74    
75     <p>
76     This tool makes sure that no two system administrators are editing this file at
77     the same time, preserves the permissions on the file and performs some syntax
78     checking to make sure you make no fatal mistakes in the file.
79     </p>
80    
81     </body>
82     </section>
83     <section>
84     <title>About this Guide</title>
85     <body>
86    
87     <p>
88     This guide is meant as a quick introduction. The <c>sudo</c> package is a lot
89     more powerful than what is described in this guide. It has special features for
90     editing files as a different user (<c>sudoedit</c>), running from within a
91     script (so it can background, read the password from standard in instead of the
92     keyboard, ...), etc.
93     </p>
94    
95 swift 1.6 <p>
96     Please read the <c>sudo</c> and <c>sudoers</c> manual pages for more
97     information.
98     </p>
99    
100 swift 1.1 </body>
101     </section>
102     </chapter>
103    
104     <chapter>
105     <title>Sudoers Syntax</title>
106     <section>
107     <title>Basic Syntax</title>
108     <body>
109    
110     <p>
111     The most difficult part of <c>sudo</c> is the <path>/etc/sudoers</path> syntax.
112     The basic syntax is like so:
113     </p>
114    
115     <pre caption="Basic /etc/sudoers syntax">
116     user host = commands
117     </pre>
118    
119     <p>
120     This syntax tells <c>sudo</c> that the user, identified by <e>user</e> and
121 swift 1.13 logged in on the system <e>host</e> can execute any of the commands listed
122 swift 1.1 in <e>commands</e> as the root user. A more real-life example might make this
123     more clear: allow the user <e>swift</e> to execute <c>emerge</c> if he is logged
124 swift 1.13 in on localhost:
125 swift 1.1 </p>
126    
127     <pre caption="Live /etc/sudoers examples">
128     swift localhost = /usr/bin/emerge
129     </pre>
130    
131 swift 1.13 <note>
132     The hostname must match what the <c>hostname</c> command returns.
133     </note>
134    
135 swift 1.1 <p>
136 swift 1.2 A <brite>big warning</brite> is in place though: do not allow a user to run an
137     application that can allow people to elevate privileges. For instance, allowing
138 swift 1.12 users to execute <c>emerge</c> as root can indeed grant them full root access
139     to the system because <c>emerge</c> can be manipulated to change the live file
140 swift 1.5 system to the user's advantage. If you do not trust your <c>sudo</c> users,
141 swift 1.4 don't grant them any rights.
142 swift 1.2 </p>
143    
144 swift 1.4 <!--
145     Wrappers are no real advantage here either, see #71750
146     -->
147    
148 swift 1.2 <p>
149 swift 1.12 The user name can also be substituted with a group name - in this case you
150     should start the group name with a <c>%</c> sign. For instance, to allow any
151 swift 1.3 one in the <c>wheel</c> group to execute <c>emerge</c>:
152 swift 1.1 </p>
153    
154     <pre caption="Allowing the wheel group members to execute emerge">
155     %wheel localhost = /usr/bin/emerge
156     </pre>
157    
158     <p>
159     You can extend the line to allow for several commands (instead of making a
160     single entry for each command). For instance, to allow the same user to not only
161     run <c>emerge</c> but also <c>ebuild</c> and <c>emerge-webrsync</c> as root:
162     </p>
163    
164     <pre caption="Multiple commands">
165     swift localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync
166     </pre>
167    
168     <p>
169     You can also specify a precise command and not only the tool itself. This is
170 swift 1.12 useful to restrict the use of a certain tool to a specified set of command
171     options. The <c>sudo</c> tool allows shell-style wildcards (AKA meta or glob
172     characters) to be used in pathnames as well as command line arguments in the
173     sudoers file. Note that these are <e>not</e> regular expressions.
174 swift 1.1 </p>
175    
176     <p>
177     Let us put this to the test:
178     </p>
179    
180     <pre caption="Attempt to update the system using sudo">
181     $ <i>sudo emerge -uDN world</i>
182    
183     We trust you have received the usual lecture from the local System
184     Administrator. It usually boils down to these three things:
185    
186     #1) Respect the privacy of others.
187     #2) Think before you type.
188     #3) With great power comes great responsibility.
189    
190     Password: <comment>(Enter the user password, not root!)</comment>
191     </pre>
192    
193     <p>
194 swift 1.5 The password that <c>sudo</c> requires is the user's own password. This is to
195 swift 1.1 make sure that no terminal that you accidentally left open to others is abused
196     for malicious purposes.
197     </p>
198    
199     <p>
200     You should know that <c>sudo</c> does not alter the <c>${PATH}</c> variable: any
201     command you place after <c>sudo</c> is treated from <e>your</e> environment. If
202     you want the user to run a tool in for instance <path>/sbin</path> he should
203     provide the full path to <c>sudo</c>, like so:
204     </p>
205    
206     <pre caption="Using the full path to a tool">
207     $ <i>sudo /usr/sbin/emerge-webrsync</i>
208     </pre>
209    
210     </body>
211     </section>
212     <section>
213     <title>Using Aliases</title>
214     <body>
215    
216     <p>
217     In larger environments having to enter all users over and over again (or hosts,
218     or commands) can be a daunting task. To ease the administration of
219     <path>/etc/sudoers</path> you can define <e>aliases</e>. The format to declare
220     aliases is quite simple:
221     </p>
222    
223     <pre caption="Declaring aliases in /etc/sudoers">
224     Host_Alias hostalias = hostname1, hostname2, ...
225     User_Alias useralias = user1, user2, ...
226     Cmnd_Alias cmndalias = command1, command2, ...
227     </pre>
228    
229     <p>
230     One alias that always works, for any position, is the <c>ALL</c> alias (to make
231     a good distinction between aliases and non-aliases it is recommended to use
232 swift 1.12 capital letters for aliases). As you might undoubtedly have guessed, the
233 swift 1.1 <c>ALL</c> alias is an alias to all possible settings.
234     </p>
235    
236     <p>
237     A sample use of the <c>ALL</c> alias to allow <e>any</e> user to execute the
238     <c>shutdown</c> command if he is logged on locally is:
239     </p>
240    
241     <pre caption="Allowing any user to execute shutdown">
242     ALL localhost = /sbin/shutdown
243     </pre>
244    
245     <p>
246     Another example is to allow the user <c>swift</c> to execute the <c>emerge</c>
247     command as root, regardless of where he is logged in from:
248     </p>
249    
250     <pre caption="Allowing a user to run an application regardless of his location">
251     swift ALL = /usr/bin/emerge
252     </pre>
253    
254     <p>
255     More interesting is to define a set of users who can run software administrative
256     applications (such as <c>emerge</c> and <c>ebuild</c>) on the system and a group
257 swift 1.5 of administrators who can change the password of any user, except root!
258 swift 1.1 </p>
259    
260     <pre caption="Using aliases for users and commands">
261     User_Alias <i>SOFTWAREMAINTAINERS</i> = swift, john, danny
262     User_Alias <i>PASSWORDMAINTAINERS</i> = swift, sysop
263     Cmnd_Alias <i>SOFTWARECOMMANDS</i> = /usr/bin/emerge, /usr/bin/ebuild
264 neysx 1.8 Cmnd_Alias <i>PASSWORDCOMMANDS</i> = /usr/bin/passwd [a-zA-Z0-9_-]*, !/usr/bin/passwd root
265 swift 1.1
266     <i>SOFTWAREMAINTAINERS</i> localhost = <i>SOFTWARECOMMANDS</i>
267     <i>PASSWORDMAINTAINERS</i> localhost = <i>PASSWORDCOMMANDS</i>
268     </pre>
269    
270     </body>
271     </section>
272     <section>
273     <title>Non-Root Execution</title>
274     <body>
275    
276     <p>
277     It is also possible to have a user run an application as a different, non-root
278     user. This can be very interesting if you run applications as a different user
279     (for instance <c>apache</c> for the web server) and want to allow certain users
280     to perform administrative steps as that user (like killing zombie processes).
281     </p>
282    
283     <p>
284 swift 1.12 Inside <path>/etc/sudoers</path> you list the user(s) in between
285 swift 1.1 <c>(</c>&nbsp;and&nbsp;<c>)</c> before the command listing:
286     </p>
287    
288     <pre caption="Non-root execution syntax">
289     users hosts = (run-as) commands
290     </pre>
291    
292     <p>
293     For instance, to allow <c>swift</c> to run the <c>kill</c> tool as the
294     <c>apache</c> or <c>gorg</c> user:
295     </p>
296    
297     <pre caption="Non-root execution example">
298     Cmnd_Alias KILL = /bin/kill, /usr/bin/pkill
299    
300     swift ALL = (apache, gorg) KILL
301     </pre>
302    
303     <p>
304     With this set, the user can run <c>sudo&nbsp;-u</c> to select the user he wants
305     to run the application as:
306     </p>
307    
308     <pre caption="Running pkill as the apache user">
309     $ <i>sudo -u apache pkill apache</i>
310     </pre>
311    
312     <p>
313     You can set an alias for the user to run an application as using the
314     <c>Runas_Alias</c> directive. Its use is identical to the other <c>_Alias</c>
315     directives we have seen before.
316     </p>
317    
318     </body>
319     </section>
320     <section>
321     <title>Passwords and Default Settings</title>
322     <body>
323    
324     <p>
325     By default, <c>sudo</c> asks the user to identify himself using his own
326     password. Once a password is entered, <c>sudo</c> remembers it for 5 minutes,
327     allowing the user to focus on his tasks and not repeatedly re-entering his
328     password.
329     </p>
330    
331     <p>
332     Of course, this behavior can be changed: you can set the <c>Defaults:</c>
333     directive in <path>/etc/sudoers</path> to change the default behavior for a
334     user.
335     </p>
336    
337     <p>
338     For instance, to change the default 5 minutes to 0 (never remember):
339     </p>
340    
341     <pre caption="Changing the timeout value">
342     Defaults:swift timestamp_timeout=0
343     </pre>
344    
345     <p>
346     A setting of <c>-1</c> would remember the password indefinitely (until the
347     system reboots).
348     </p>
349    
350     <p>
351     A different setting would be to require the password of the user that the
352 swift 1.12 command should be run as and not the users' personal password. This is
353 swift 1.1 accomplished using <c>runaspw</c>. In the following example we
354     also set the number of retries (how many times the user can re-enter a password
355     before <c>sudo</c> fails) to <c>2</c> instead of the default 3:
356     </p>
357    
358 swift 1.5 <pre caption="Requiring the root password instead of the user's password">
359 swift 1.1 Defaults:john runaspw, passwd_tries=2
360     </pre>
361    
362     <p>
363 swift 1.7 Another interesting feature is to keep the <c>DISPLAY</c> variable set so that
364     you can execute graphical tools:
365     </p>
366    
367     <pre caption="Keeping the DISPLAY variable alive">
368     Defaults:john env_keep=DISPLAY
369     </pre>
370    
371     <p>
372 swift 1.1 You can change dozens of default settings using the <c>Defaults:</c> directive.
373     Fire up the <c>sudo</c> manual page and search for <c>Defaults</c>.
374     </p>
375    
376     <p>
377     If you however want to allow a user to run a certain set of commands without
378     providing any password whatsoever, you need to start the commands with
379     <c>NOPASSWD:</c>, like so:
380     </p>
381    
382     <pre caption="Allowing emerge to be ran as root without asking for a password">
383     swift localhost = NOPASSWD: /usr/bin/emerge
384     </pre>
385    
386     </body>
387     </section>
388     </chapter>
389    
390     <chapter>
391     <title>Using Sudo</title>
392     <section>
393     <title>Listing Privileges</title>
394     <body>
395    
396     <p>
397     To inform yourself what your capabilities are, run <c>sudo&nbsp;-l</c>:
398     </p>
399    
400     <pre caption="Listing capabilities">
401     $ <i>sudo -l</i>
402     User swift may run the following commands on this host:
403     (root) /usr/libexec/xfsm-shutdown-helper
404     (root) /usr/bin/emerge
405 neysx 1.8 (root) /usr/bin/passwd [a-zA-Z0-9_-]*
406 swift 1.1 (root) !/usr/bin/passwd root
407     (apache) /usr/bin/pkill
408     (apache) /bin/kill
409     </pre>
410    
411     <p>
412     If you have any command in <path>/etc/sudoers</path> that does not require you
413     to enter a password, it will not require a password to list the entries either.
414     Otherwise you might be asked for your password if it isn't remembered.
415     </p>
416    
417     </body>
418     </section>
419     <section>
420     <title>Prolonging the Password Timeout</title>
421     <body>
422    
423     <p>
424     By default, if a user has entered his password to authenticate himself to
425     <c>sudo</c>, it is remembered for 5 minutes. If the user wants to prolong this
426     period, he can run <c>sudo&nbsp;-v</c> to reset the time stamp so that
427     it will take another 5 minutes before <c>sudo</c> asks for the password again.
428     </p>
429    
430     <pre caption="Prolonging the password timeout">
431     $ <i>sudo -v</i>
432     </pre>
433    
434     <p>
435     The inverse is to kill the time stamp using <c>sudo&nbsp;-k</c>.
436     </p>
437    
438     </body>
439     </section>
440     </chapter>
441     </guide>

  ViewVC Help
Powered by ViewVC 1.1.20