sudo documentation is the worst ever
The prize for worst documentation ever goes to sudo.
(Of course many projects have no documentation at all. Those projects aren't in the running for the worst-documentation-ever prize.)
The sudo documentation spends the first few hundred lines telling us how the documentation is going to present the syntax for sudo in BNF. Then the documentation gives us the BNF in all it's tedious glory. We wade through symbol soup, trying to build a mental model of how /etc/sudoers works, but we can never be sure we get it because there isn't a single example in the entire section.
Finally, towards the end of the document, we get to examples. Unfortunately, examples start with an advanced topic, how to define aliases. It seems to me that 99% of all users never need to know how to create aliases.
Finally, finally, we get to some simple examples that implicitely explain how the whole thing works. It's really not so difficult, despite the documentation trying to make it seem that way.
The next section tells you most of what you need to know about configuring /etc/sudoers.
more details
Let's interpret who can do what. /etc/sudoers starts with
Next, /etc/sudoers has
sudo settings
The main purpose of /etc/sudoers is to specify who can do what as whom. It's also possible to change some settings, to modify how sudo behaves. These changes are optional; sudo will work just fine without them.
The default is to give the lecture to each user once ever. I prefer to turn off the feature by setting lecture=never.
The default is to ask the user for their password once every 5 minutes. The timestamp_timeout setting specifies, in minutes, how often the user is prompted for their password. This feature is potentially useful but also very confusing to new users. I changed timestamp_timeout=0, so that users are prompted for a password every time they use sudo.
Alternatively, you can turn off the password prompt altogether with
(Of course many projects have no documentation at all. Those projects aren't in the running for the worst-documentation-ever prize.)
The sudo documentation spends the first few hundred lines telling us how the documentation is going to present the syntax for sudo in BNF. Then the documentation gives us the BNF in all it's tedious glory. We wade through symbol soup, trying to build a mental model of how /etc/sudoers works, but we can never be sure we get it because there isn't a single example in the entire section.
Finally, towards the end of the document, we get to examples. Unfortunately, examples start with an advanced topic, how to define aliases. It seems to me that 99% of all users never need to know how to create aliases.
Finally, finally, we get to some simple examples that implicitely explain how the whole thing works. It's really not so difficult, despite the documentation trying to make it seem that way.
The next section tells you most of what you need to know about configuring /etc/sudoers.
| sudo for dummies (like me) This /etc/sudoers file illustrates all you need to know to configure sudo for the most common use cases: josh,timkay ALL=(ALL) ALLThese lines specify who is allowed to run what as whom. Lines are of the form user-list host-list=(as-user-list) commandThe user-list lists the users that can issue the specified command. A percent sign is used to specify a group rather than a user. Multiple users and groups can be listed, separated by commas. Presumably a single /etc/sudoers file will be copied to many hosts. The host-list allows the granting of different privileges on different hosts. For simple use cases, host-list is always ALL, meaning that each line applies to all hosts. The as-user-list indicates as what user the command will run. If ommitted, it defaults to root. That's probably all you need to know. |
more details
Let's interpret who can do what. /etc/sudoers starts with
josh,timkay ALL=(ALL) ALLJosh and Tim Kay can, on any host (the first ALL), run as any user (the second ALL), and can run all commands (the third ALL). Josh or Tim Kay would issue commands like these:
sudo -u prod crontab -l (see prod's crontab)Before running the command (as prod or root), sudo asks the user for their password. sudo is asking for Josh or Tim Kay's password (not root's or prod's password).
sudo su - (get a root shell)
Next, /etc/sudoers has
%eng ALL=/usr/bin/lesssays that anybody in group eng can, on any host, run /usr/bin/less as root:
sudo less /var/log/apache2/error_logThis way, users writing CGI scripts can see the error messages. (A better way is to change the relevant permissions in logrotate.d.) Finally, /etc/sudoers has
%eng ALL=(timkay) /usr/bin/killallsays anybody in group eng can, on any host, run killall as user timkay (can kill any of timkay's processes):
sudo -u timkay killall sleep
sudo settings
The main purpose of /etc/sudoers is to specify who can do what as whom. It's also possible to change some settings, to modify how sudo behaves. These changes are optional; sudo will work just fine without them.
Default lecture=neverBy default, prior to executing a command, sudo does two things: it lectures the user to behave, and it prompts a user for their password (not root's password, of course). sudo asks for the user's password to prevent others from doing nasty things at the user's keyboard while the user is away.
Default timestamp_timeout=0
The default is to give the lecture to each user once ever. I prefer to turn off the feature by setting lecture=never.
The default is to ask the user for their password once every 5 minutes. The timestamp_timeout setting specifies, in minutes, how often the user is prompted for their password. This feature is potentially useful but also very confusing to new users. I changed timestamp_timeout=0, so that users are prompted for a password every time they use sudo.
Alternatively, you can turn off the password prompt altogether with
Default !authenticateor you can add the tag NOPASSWORD: before the name of the command.
posted by Tim at 8:06 AM
0 Comments:
Post a Comment
<< Home