From: "Sven Vermeulen" <swift@lark.gentoo.org>
To: gentoo-doc-cvs@lists.gentoo.org
Subject: [gentoo-doc-cvs] cvs commit: sudo-guide.xml
Date: Tue, 2 Aug 2005 16:14:21 +0000 [thread overview]
Message-ID: <200508021614.j72GEEkR027346@robin.gentoo.org> (raw)
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="swift@gentoo.org">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
--
gentoo-doc-cvs@gentoo.org mailing list
next reply other threads:[~2005-08-02 16:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-02 16:14 Sven Vermeulen [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-08-02 17:48 [gentoo-doc-cvs] cvs commit: sudo-guide.xml Sven Vermeulen
2005-08-02 17:59 Sven Vermeulen
2005-08-02 18:00 Sven Vermeulen
2005-08-02 19:22 Sven Vermeulen
2005-08-02 19:23 Sven Vermeulen
2005-08-03 8:13 Sven Vermeulen
2005-08-04 8:05 swift
2005-08-04 8:07 swift
2005-10-21 20:21 swift
2005-12-31 15:30 Xavier Neys
2006-07-14 11:46 Xavier Neys
2008-05-19 20:45 Sven Vermeulen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200508021614.j72GEEkR027346@robin.gentoo.org \
--to=swift@lark.gentoo.org \
--cc=docs-team@lists.gentoo.org \
--cc=gentoo-doc-cvs@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox