How should I add a narrowly scoped sudo rule without breaking administrator access?
Sudo rules should grant only the required command and target identity. Use visudo because it checks syntax before installing a policy change. A command that can launch a shell, edit arbitrary files or execute plugins may grant much more authority than its name suggests.
Before you start
- An existing administrator is authorised to change sudo policy and retains a separate working session.
Instructions
1. Confirm the existing policy and exact executable
An existing administrator should inspect the account’s policy and identify the actual service and executable path. This example concerns reading one service’s state only.
sudo -l -U adminuser
command -v systemctlDo not copy an executable path from another distribution without checking it locally.
2. Edit an approved policy fragment
Use the policy’s established include directory and naming convention. Within the editor, a reviewed example is adminuser ALL=(root) /usr/bin/systemctl is-active example.service, only if that is the verified path and service.
sudo visudo -f /etc/sudoers.d/adminuser-service-status
sudo visudo -cThe first command edits the scoped rule; the second checks the full policy. Avoid passwordless access unless the approved design requires it.
Check the result
- From the named account, sudo -l displays the intended restriction and the exact status command works. An unrelated privileged command remains unauthorised.
Troubleshooting
- visudo reports a syntax error
- Return to the editor and correct the rule. Do not force-save an invalid policy.
- The fragment is ignored
- Review the includedir configuration and file ownership, mode and filename rules with the authorised administrator.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.