Delegating commands with sudo

You put your rule in a separate file in /etc/sudoers.d: it is easy to see, easy to remove, and the main /etc/sudoers stays untouched.

The file has three requirements. The name has no dot and no trailing ~: sudo silently skips files like labops.conf. The owner is root:root. The mode is 0440. visudo -f creates a new file with mode 0640, so a chmod is needed after saving:

bash

sudo EDITOR=vim visudo -f /etc/sudoers.d/labops
sudo chmod 0440 /etc/sudoers.d/labops
sudo visudo -c

sudo visudo -c checks the whole configuration: /etc/sudoers and every included file, permissions included. For a file with mode 0640 it prints bad permissions, should be mode 0440.

Warning

On this machine sudo skips a line with an error and prints the error on every call; older sudo versions refuse to work at all after such an error. So sudoers files are edited only with visudo, and on a server you keep a second terminal open with sudo -i.

Check yourself 1 question

You created the rule file with sudo tee. What do you do?

$ sudo visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/90-student: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/ops: bad permissions, should be mode 0440

Then every file in the directory stops working, 90-student included. The problem is one file's permissions.
visudo -c checks permissions too: for ops it printed bad permissions and exited with an error. The file must be 0440.
sudo skips files with a dot in the name: the error goes away together with the rule. You fix the file's own permissions.

tee created the file with ordinary permissions, while sudo requires 0440. chmod 0440 fixes exactly that, and running sudo visudo -c again prints parsed OK for every file.

Key points

A rule file in /etc/sudoers.d: a name without a dot, root:root, mode 0440.
visudo -c checks the whole configuration, file permissions included, but not what the rules mean.

Delegating commands with sudo

Signing in is needed to start the machine