Terminal.Drill Get the app
ch04/l03

Sudo and privilege boundaries

Use elevated privileges as a scoped action, not a working mode.

sudo -l 20 min read, 25 min lab foundation

`sudo` runs a command with elevated privileges according to policy. It should be used for the specific operation that needs privilege, after read-only checks have narrowed the target.

In the field

You need to restart a service, but first you should prove service state and permissions.

Worked command

$ sudo -l$ systemctl status nginx.service$ sudo systemctl restart nginx.service
Anti-pattern

Do not switch into a root shell because one command failed.

Safer pattern

Perform read-only checks first, then run one scoped privileged command if needed.

Knowledge check

A service looks broken and you have sudo. What is the operator-correct first move before any privileged change?

  • A Run read-only checks (sudo -l, systemctl status) to confirm policy and state first
  • B Open a root shell with `sudo -i` so later commands run without prompts
  • C Run `sudo systemctl restart` immediately to clear the fault fastest
  • D Recursively chown the service tree so permissions stop blocking you
Show the answer

Correct: A. Run read-only checks (sudo -l, systemctl status) to confirm policy and state first

Why

Read-only checks narrow the target and prove what is actually wrong before you spend a privileged action. A root shell turns a scoped privilege into a working mode, where one wrong command runs unguarded across the system.

Practice checklist

  1. Read `sudo -l` on a lab machine if available.
  2. Write a privileged action plan without executing it.
  3. Name the read-only checks that come first.

Deliverable evidence

  • A sudo action plan that separates read-only checks from privileged action.
Teaching diagramch04 · mental model
-rwxr----- 1 app deploy deploy.sh user rwx group r-- other --- mode = WHAT each class may do ownership owner app : group deploy WHO the classes resolve to umask 0022 subtracts default bits new files: 644 / 755 sudo scoped, after read-only change the narrowest bit, inspect before and after

shows: How a file's access splits into ownership (who) and mode bits (what) per user/group/other class, how umask seeds defaults, and where sudo crosses the boundary.

does not prove: It shows the model, not your case: only running ls -l, stat, id, and sudo -l on the actual file proves who you are and what access you currently hold.

Memorize this

Commit these to memory, then drill them until recall is automatic.

sudosudo -lleast privilegeread-only first

Reference

sudo -lsystemctl status
Recall practice · Scenario -> next check

cue Before using sudo to restart or modify a service, what comes first?

show recall target

read-only checks: sudo -l, then systemctl status <unit>

See this drill type Practice recall in the app