Sudo policy as drop-in files in /etc/sudoers.d, checked with visudo -c

Goal

Grant one account the narrowest possible sudo privilege, as a reviewable file, without risking a broken sudoers file that locks out administrative access.

Prerequisites

Root access, or an existing working sudo account; know the exact command(s) the target account needs to run and as which user.

Steps

1. Never edit /etc/sudoers or files under /etc/sudoers.d/ with a plain editor directly on the live file; always go through visudo, which locks the file and validates syntax before saving: visudo -f /etc/sudoers.d/deploy-restart.
2. Write the narrowest rule that satisfies the need — a specific command, specific arguments, and a specific target user, not ALL: deploy ALL=(root) /usr/bin/systemctl restart myapp.service Avoid NOPASSWD:ALL or an unrestricted command list; both let the grantee run anything as root, including editing files that grant themselves more, which defeats the point of scoping the rule at all. If a script is the sudo target, treat it as the actual privilege boundary — anything that script can be made to do runs as root.
3. Mind the file name: sudo skips files in /etc/sudoers.d/ whose names end in ~ or contain a ., so deploy.conf is silently ignored while deploy-restart is read. Keep the mode at 0440, owned by root. Validate the file without applying it, useful in a non-interactive or scripted deployment: visudo -c -f /etc/sudoers.d/deploy-restart performs a check-only syntax validation and reports errors without opening an editor.
4. Confirm the rule is honored, from the target account: sudo -l -U deploy lists what it is allowed to run; sudo -u deploy sudo /usr/bin/systemctl restart myapp.service exercises it directly.
5. Check what sudo actually logs: successful and failed sudo invocations go to the system journal/syslog via the authpriv/auth facility by default; review with journalctl -t sudo or the distribution's mail/security log.

Expected result

visudo -c reports no syntax errors; sudo -l -U deploy shows exactly the intended command and nothing broader; the journal shows an entry for each use.

Limits and test basis

Based on sudoers(5) and visudo(8). To undo, remove the drop-in file (rm /etc/sudoers.d/deploy-restart) — never remove the base /etc/sudoers file itself. Because visudo locks and validates, a mistake there cannot corrupt the live policy; the same protection does not extend to a file edited outside visudo and only checked afterward, so always create or edit sudoers content through visudo -f, not a separate editor followed by a visudo -c check.