swift 05/08/02 17:59:29 Modified: xml/htdocs/doc/en metadoc.xml Added: xml/htdocs/doc/en sudo-guide.xml Log: Committing sudo(ers) guide
Revision Changes Path 1.93 +6 -1 xml/htdocs/doc/en/metadoc.xml file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/metadoc.xml?rev=1.93&content-type=text/x-cvsweb-markup&cvsroot=gentoo plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/metadoc.xml?rev=1.93&content-type=text/plain&cvsroot=gentoo diff : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/metadoc.xml.diff?r1=1.92&r2=1.93&cvsroot=gentoo Index: metadoc.xml =================================================================== RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/metadoc.xml,v retrieving revision 1.92 retrieving revision 1.93 diff -u -r1.92 -r1.93 --- metadoc.xml 1 Aug 2005 15:52:23 -0000 1.92 +++ metadoc.xml 2 Aug 2005 17:59:29 -0000 1.93 @@ -1,5 +1,5 @@ <?xml version='1.0' encoding="UTF-8"?> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/metadoc.xml,v 1.92 2005/08/01 15:52:23 swift Exp $ --> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/metadoc.xml,v 1.93 2005/08/02 17:59:29 swift Exp $ --> <!DOCTYPE metadoc SYSTEM "/dtd/metadoc.dtd"> <metadoc lang="en"> @@ -362,6 +362,7 @@ <file id="apache-troubleshooting">/doc/en/apache-troubleshooting.xml</file> <file id="apache-upgrading">/doc/en/apache-upgrading.xml</file> <file id="apache-developer">/doc/en/apache-developer.xml</file> + <file id="sudo-guide">/doc/en/sudo-guide.xml</file> </files> <docs> <doc id="name-logo"> @@ -994,5 +995,9 @@ <memberof>gentoodev_docs</memberof> <fileid>apache-developer</fileid> </doc> + <doc id="sudo-guide"> + <memberof>sysadmin_general</memberof> + <fileid>sudo-guide</fileid> + </doc> </docs> </metadoc> 1.1 xml/htdocs/doc/en/sudo-guide.xml file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/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/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/sudo-guide.xml,v 1.1 2005/08/02 17:59:29 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>1.0</version> <date>2005-08-02</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 right 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 (successful 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> The user name can also be substituted with a group name - in this case you should start the group name with a <c>%</c> sign. For instance, to allow any one in the <c>wheel</c> group to execute <c>emerge</c>: </p> <pre caption="Allowing the wheel group members to execute emerge"> %wheel 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> -- [email protected] mailing list
