上QQ阅读APP看书，第一时间看更新

Limiting the user's actions with commands

Let's say that you create a sudo rule so that Sylvester can use the systemctl command:

sylvester ALL=(ALL) /usr/bin/systemctl

This allows Sylvester to have full use of the systemctl features. He can control daemons, edit service files, shut down or reboot, and carry out every other function that systemctl does. That's probably not what you want. It would be better to specify what systemctl functions that Sylvester is allowed to do. Let's say that you want him to be able to control just the Secure Shell service. You can make the line look like this:

sylvester ALL=(ALL) /usr/bin/systemctl * sshd

Sylvester can now do everything he needs to do with the Secure Shell service, but he can't shut down or reboot the system, edit other service files, or change systemd targets. But what if you want Sylvester to do only certain specific actions with the Secure Shell service? Then you'll have to omit the wildcard and specify all of the actions that you want Sylvester to do:

sylvester ALL=(ALL) /usr/bin/systemctl status sshd, /usr/bin/systemctl restart sshd

Now, Sylvester can only restart the Secure Shell service or check its status.

When writing sudo policies, you'll want to be aware of the differences between the different Linux and Unix distributions on your network. For example, on Red Hat and CentOS systems, the systemctl binary file is located in the /usr/bin directory. On Debian/Ubuntu systems, it's located in the /bin directory. If you have to roll out a sudoers file to a large enterprise network with mixed operating systems, you can use host aliases to ensure that servers will only allow the execution of commands that are appropriate for their operating systems.

Also, be aware that some system services have different names on different Linux distributions. On Red Hat and CentOS systems, the Secure Shell service is sshd. On Debian/Ubuntu systems, it's just plain ssh.