The essentials
Quick reference
One focused task per row. Jump to the related section for complete, working examples.
| Use | Syntax | Examples |
|---|---|---|
| List your privileges | sudo -l | View examples |
| List detailed privileges | sudo -ll | View examples |
| Inspect another user's policy | sudo -U releasebot -ll | View examples |
| Validate the complete policy | sudo visudo --check | View examples |
| Parse one policy fragment | sudo visudo --check \
--file=/etc/sudoers.d/release-operators | View examples |
| Safely edit a policy fragment | sudo visudo --file=/etc/sudoers.d/release-operators | View examples |
| Define an operator alias | User_Alias RELEASE_OPERATORS = %release-operators | View examples |
| Define an exact command alias | Cmnd_Alias API_STATUS = /usr/bin/systemctl --no-pager \
status api.service | View examples |
| Grant a read-only service check | RELEASE_OPERATORS ALL = (root) API_STATUS | View examples |
| Grant one noninteractive action | releasebot ALL = (root) NOPASSWD: /usr/bin/systemctl \
restart api.service | View examples |
| Invalidate your timestamp | sudo -k | View examples |
| Set a controlled command path | Defaults:%release-operators \
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" | View examples |
| Enable I/O logging for a group | Defaults:%release-operators log_input,log_output | View examples |
| List recorded sessions | sudo sudoreplay --list | View examples |
| Test one exact authorization | sudo -U releasebot -l /usr/bin/systemctl restart \
api.service | View examples |
sudoers is executable security policy: a small matching mistake can grant a root-capable escape path or lock administrators out. Delegate the narrowest exact command and run-as identity that satisfies the operational task, keep privileged programs and their configuration outside the delegate's write control, and treat NOPASSWD, SETENV, shells, editors, pagers, package managers, and unrestricted wildcards as high-risk. Edit with visudo, validate the complete include graph, inspect the effective policy, and retain an independently tested recovery session for every rollout.
Step by step
Detailed examples
Inspect effective privileges before and after a change
sudoers combines user, host, run-as, command, tag, and Defaults matches across the main file and included policy sources. Group membership and external directory services can also affect the result. Use sudo -l as the target user where possible; inspecting another user with -U requires authorization. Detailed -ll output is especially useful on newer sudo releases because it can identify the source entry that matched.
sudo -l
sudo -ll
# An authorized administrator can inspect the automation identity:
# sudo -U releasebot -llEdit with locking and validate the whole include graph
visudo locks policy during interactive editing and refuses to install syntax it considers invalid. Check mode returns zero only on success. A selected file check is useful while developing a fragment, but the final gate must validate the default policy and all includes, including ownership and mode checks. Keep a known-good root session open, deploy atomically through configuration management, and never choose visudo's force-save path after a reported syntax error.
sudo visudo --file=/etc/sudoers.d/release-operators
sudo visudo --check --file=/etc/sudoers.d/release-operators
sudo visudo --checkBind an exact task to an exact run-as identity
A privilege specification should name who may run which absolute executable, on which host, and as which target identity. Restrict arguments whenever the program has unrelated subcommands or flags. Exact sudoers argument matching includes whitespace and metacharacter rules, so verify the result with sudo -l. The service unit, executable, working directories, configuration, and any files it loads must not be writable by the delegate; otherwise a narrow restart permission can become arbitrary root execution.
User_Alias RELEASE_OPERATORS = %release-operators
Cmnd_Alias API_STATUS = /usr/bin/systemctl --no-pager status api.service
RELEASE_OPERATORS ALL = (root) API_STATUSUse NOPASSWD only for a controlled automation identity
By default, sudo authenticates the invoking user and caches a credential timestamp according to policy. NOPASSWD removes that interactive barrier; it does not make a command intrinsically safe. Reserve it for noninteractive identities with constrained login, narrowly writable inputs, exact commands, monitoring, and revocation. Operators can use sudo -k to invalidate their cached timestamp. Avoid granting general shells or ALL merely to make an automation workflow convenient.
# releasebot must not be able to modify api.service, its executable, or loaded configuration.
releasebot ALL = (root) NOPASSWD: /usr/bin/systemctl restart api.service
# Interactive operators can invalidate their own cached credential with: sudo -kTreat environment control and program escapes as privilege
SETENV and unsafe env_keep entries can let a caller influence library loading, interpreters, configuration, or child commands. Use env_reset and a controlled secure_path, and pass only task-specific variables proven safe. Editors, pagers, shells, interpreters, debuggers, archive tools, and package managers commonly provide command escapes. NOEXEC can reduce some dynamically linked child execution but is not a security boundary and can be bypassed; prefer a purpose-built root helper with strict input validation when an application is too powerful to delegate directly.
Defaults:%release-operators env_reset
Defaults:%release-operators secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
# Do not preserve loader, interpreter, pager, or editor variables for privileged commands.Log delegated activity without mistaking logs for prevention
sudo logs policy decisions, and optional I/O logging records terminal streams for later sudoreplay review. Input logs may capture passwords, tokens, personal data, or regulated content, so restrict access, retention, forwarding, and storage before enabling them. Logging supports detection and accountability but does not neutralize an overpowered command. Alert on denials and unusual targets, review effective privileges periodically, and remove stale delegation promptly.
# Policy line: Defaults:%release-operators log_input,log_output
sudo sudoreplay --list
sudo visudo --checkAvoid blacklist-shaped policy and rehearse rollback
A broad grant followed by exclusions such as ALL except a named shell is unsafe: users can often reach equivalent interpreters, command escapes, writable scripts, or alternate paths. Wildcards in command arguments are also easy to overmatch because they can span whitespace. Build an allowlist from the operational procedure, test allowed and denied invocations using the exact packaged sudo version, validate all includes, and roll out with a preserved administrative session and a version-controlled known-good policy.
1. Review the allowlist, run-as target, arguments, writable inputs, and escape surface.
2. Parse the fragment, then validate the complete policy with visudo --check.
3. Verify allowed and denied cases with sudo -l using the target identity.
4. Keep independent recovery access until the deployed policy is proven.Sources and further reading
References
Authoritative documentation used to verify and expand this cheat sheet.
Help us improve
Found a typo or missing example?
Tell us what would make this cheat sheet clearer, more complete, or more useful.