Penguin
Note: You are viewing an old revision of this page. View the current version.

A short guide to setting up sudo(1)

sudo is configured in the /etc/sudoers file, which is documented in sudoers(5)?. Unfortunately, that ManPage seems written for people who want to write a clone of sudo, rather than use it, so it is unnecessarily difficult to understand the syntax by reading its documentation. The task is further complicated by the fact that the syntax is somewhat baroque.

Hint to the sudo programmers: humans are not yacc parsers, so a parser grammar is not suitable documentation.

Be aware that sudo(1) is very picky about correct syntax in its configuration file and will refuse to work if you make the slightest mistake. (Considering that sudo(1) can grant SuperUser privileges, this is not an entirely bad idea, user-unfriendly as it may be.) Therefore, you should use the visudo(1)? tool to edit the file, rather than opening it directly. visudo will check your changes for correctness after saving them, and will inform you of any errors, in which case it will offer to reject the changes or re-edit the file. Of course, visudo itself requires SuperUser privileges, so launch it using su -c visudo.

Note that visudo may insist on making you use vi(1) to edit the file, though some configurations may respect your choice of TextEditor according to the EDITOR/VISUAL EnvironmentVariables. If this bugs you, edit /etc/sudoers with another editor, then use visudo -c to check it for correctness. (You can add an incantation to /etc/sudoers to tell visudo what EDITOR/VISUAL settings to respect, but that's pointless to discuss here since most people are only ever going to edit the file once.)

With all that said, let's proceed to the disproportionately short piece of configuration text that all this noise had to be made about. Copy the following line into the file:

%wheel ALL=(ALL) NOPASSWD: ALL

That's it. Now all users in the group wheel, by longstanding Unix tradition the group which contains the SystemAdministrators, will be able to use sudo to invoke any command, running as any user (but defaulting to root), without being prompted for a password. Of course, this requires putting your regular user account in that group; if there really will only ever be one user to use sudo on your machine, you can omit this step by using the line

username ALL=(ALL) NOPASSWD: ALL

A longer guide to setting up sudo(1)

sudo offers many more capabilities than just letting one or more users do anything at all as anyone at all. That flexibility is why it's so hard to configure in the first place, and is very useful in actual multi-user situations, where some users only need to be able to do one (or a few) specific thing(s) requiring SuperUser privileges.

F.ex., such a scenario might involve a webmaster who should be able to restart the WebServer which runs as root, and be able to kill any processes which run as wwwuser or some other unprivileged account that the WebServer uses to actually deliver pages, but should not have full root access to the machine.

However, I mostly wanted to have a quick description on how to set up sudo(1) for people who run Linux on their home PCs, so I'm not going to go into that here and now. I may come back to this at some point. In the meantime, there is useful material about that available via Google. --AristotlePagaltzis

Common Misconceptions About sudo(1) and Security

NB: the following section applies mainly to more sophisticated setups of sudo(1) than the one shown in the Short guide above.

Since its inception, the possibility that providing SuperUser access on a normal user password could represent a security hole has tickled the imagination of Hacker and user alike. While there have been special cases of misusing sudo(1) so as to circumvent network security, some security bulletins would seem to make more of the issue than there is. The purpose of this section is to clear up misconceptions that commonly occur about the use of sudo(1) in practise. Hopefully, this will allow sysadmins and users, concerned about security, to direct their energies to more serious issues.

sudo(1) does not allow unverified SuperUser access to a normal user. This misconception that it does comes from a misreading of the sudo(1) man page. One understands that after first invoking sudo(1), one no longer need enter a password for future uses (within a time limit). One also understands that the user access has been upgraded for the duration of this time limit. This leads to the following possible uses coming tomind
$ sudo iptables -L
password:
<iptables information>
... time, less than 5 mins, passes ...
$ iptables -L

The second invocation of iptables(8) would fail. The user cannot execute commands which require SuperUser privileges directly. To execute this command without requiring a password, the user would have to enter sudo iptables -L.

$ sudo iptables -L
password:
<iptables information>
... time, less than 5 mins, passes ...
$ sudo mount <some file system at some mountpoint>

Here, because the commands differ, the invocation of mount(8) would still require a password -- even though sudo(1) has already been invoked and verified within the "magic" 5 min time frame. (Note: Superuser access in not required to mount(2) a filesystem, provided it is entered in fstab(5) with the "user" option.)

sudo(1) does not grant SuperUser access to users. It grants access to particular commands to users. Only the permitted commands can be subsequently invoked via sudo(1) without a password by the originally invoking user. The following example shows the correct behavior
$ sudo whoami
password:
root
$ whoami
user
$ sudo whoami
root
$ sudo whereis sudo
password:
sudo: /usr/bin/sudo /usr/share/man/man8/sudo.8.gz

The first invocation of sudo(1) for the whoami(1) command required a password. Invoking whoami(1) without sudo(1) shows that you are still a normal user. Future invocations of whoami with the aid of sudo(1) do not require a password. Attempting to sudo(1) any other command will requires a password. (Note: whereis does not need root to be used, but sudo(1) requires verification anyway: it is not verifying your right to use the command, but your right to use sudo(1).)