swift 05/08/02 16:14:21 Added: xml/htdocs/doc/en/draft sudo-guide.xml Log: Sudo guide, draft
Revision Changes Path 1.1 xml/htdocs/doc/en/draft/sudo-guide.xml 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 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 Index: sudo-guide.xml =================================================================== <?xml version='1.0' encoding="UTF-8"?> <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/sudo-guide.xml,v 1.1 2005/08/02 16:14:21 swift Exp $ --> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> <guide link="/doc/en/sudo-guide.xml"> <title>Gentoo Sudo(ers) Guide</title> <author title="Author"> <mail link="[EMAIL PROTECTED]">Sven Vermeulen</mail> </author> <abstract> 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. </abstract> <!-- The content of this document is licensed under the CC-BY-SA license --> <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> <license/> <version>0.1</version> <date>2005-01-01</date> <chapter> <title>About Sudo</title> <section> <title>Granting Permissions</title> <body> <p> The <c>app-admin/sudo</c> package allows the system administrator to grant permission to other users to execute one or more applications they would normally have no access to. Unlike using the <e>setuid</e> bit on these applications <c>sudo</c> gives a more fine-grained control on <e>who</e> can execute a certain command and <e>when</e>. </p> <p> With <c>sudo</c> you can make a clear list <e>who</e> 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 and you can even fine-tune the permissions based on the location where the user is at: if he is logged on from the system itself or through SSH from a remote site. </p> </body> </section> <section> <title>Logging Activity</title> <body> <p> One additional advantage of <c>sudo</c> is that it can log any attempt (succesful 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 :) </p> </body> </section> <section> <title>Configuring Sudo</title> <body> <p> The <c>sudo</c> configuration is managed by the <path>/etc/sudoers</path> file. This file should never be edited through <c>nano /etc/sudoers</c> or <c>vim /etc/sudoers</c> or any other editor you might like. When you want to alter this file, you should use <c>visudo</c>. </p> <p> 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. </p> </body> </section> <section> <title>About this Guide</title> <body> <p> This guide is meant as a quick introduction. The <c>sudo</c> package is a lot more powerful than what is described in this guide. It has special features for editing files as a different user (<c>sudoedit</c>), running from within a script (so it can background, read the password from standard in instead of the keyboard, ...), etc. </p> </body> </section> </chapter> <chapter> <title>Sudoers Syntax</title> <section> <title>Basic Syntax</title> <body> <p> The most difficult part of <c>sudo</c> is the <path>/etc/sudoers</path> syntax. The basic syntax is like so: </p> <pre caption="Basic /etc/sudoers syntax"> user host = commands </pre> <p> This syntax tells <c>sudo</c> that the user, identified by <e>user</e> and logged on through the system <e>host</e> can execute any of the commands listed in <e>commands</e> as the root user. A more real-life example might make this more clear: allow the user <e>swift</e> to execute <c>emerge</c> if he is logged on from the system (not through SSH): </p> <pre caption="Live /etc/sudoers examples"> swift localhost = /usr/bin/emerge </pre> <p> 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 <c>emerge</c> but also <c>ebuild</c> and <c>emerge-webrsync</c> as root: </p> <pre caption="Multiple commands"> swift localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync </pre> <p> 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 <c>sudo</c> tool allows for regular expressions to be used as well. </p> <p> Let us put this to the test: </p> <pre caption="Attempt to update the system using sudo"> $ <i>sudo emerge -uDN world</i> 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: <comment>(Enter the user password, not root!)</comment> </pre> <p> The password that <c>sudo</c> requires is the user his own password. This is to make sure that no terminal that you accidentally left open to others is abused for malicious purposes. </p> <p> You should know that <c>sudo</c> does not alter the <c>${PATH}</c> variable: any command you place after <c>sudo</c> is treated from <e>your</e> environment. If you want the user to run a tool in for instance <path>/sbin</path> he should provide the full path to <c>sudo</c>, like so: </p> <pre caption="Using the full path to a tool"> $ <i>sudo /usr/sbin/emerge-webrsync</i> </pre> </body> </section> <section> <title>Using Aliases</title> <body> <p> 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 <path>/etc/sudoers</path> you can define <e>aliases</e>. The format to declare aliases is quite simple: </p> <pre caption="Declaring aliases in /etc/sudoers"> Host_Alias hostalias = hostname1, hostname2, ... User_Alias useralias = user1, user2, ... Cmnd_Alias cmndalias = command1, command2, ... </pre> <p> One alias that always works, for any position, is the <c>ALL</c> alias (to make a good distinction between aliases and non-aliases it is recommended to use -- [email protected] mailing list
