sudo and least privilege

sudo is a policy boundary

sudo runs an allowed command as another identity, commonly root. It is not simply a prefix for commands that fail. The policy can depend on the calling user, target user, command, arguments, and authentication requirements.

Inspect your own permitted operations on the VM:

sudo -l

It may ask for your password or deny access. Both are useful observations. Do not paste the password or policy output containing private paths into public notes.

Judge the command's real power

Permission to run an editor, shell, package installer, or arbitrary script as root can effectively grant broad administrative access. Even permission to restart one service can be dangerous if the same user can modify that service's executable or unit file. Review file ownership and command arguments together.

Administrators should edit sudo policy with visudo, which checks syntax, and keep a working recovery session. This lesson asks you to review a hypothetical grant for restarting one known service; it does not provide an untested policy to install on your host.

Read a hypothetical rule

This is a policy-reading example, not a file to install:

site-operator ALL=(root) /usr/bin/systemctl restart personal-site.service

site-operator identifies the caller; ALL here is the host list; (root) chooses the target user; the remainder specifies an executable and arguments. Without NOPASSWD, the normal policy's authentication rules apply. Merely counting one executable does not establish least privilege: ask what code that executable causes root to run.

Imagine the service runs a script that site-operator can edit. Restart authority would then let that account influence a root-run program. The unit, executable, configuration, and parent directories all need appropriate ownership and permissions. A pager or editor with shell escapes can also make an apparently narrow grant much broader.

Use sudo -l to compare this example with your own actual grant. OrbStack commonly provides convenient passwordless sudo for the local learning user; record that as an environment property, not a production policy recommendation. You do not need to change it to complete this course.

The goal of least privilege is enough authority for the intended job with unnecessary authority removed. It is not “everything without a password” or “one command regardless of what it can do.” Administrators validate syntax with visudo -c and review semantics separately: valid syntax can still grant excessive power.

Shell redirection happens separately

In sudo echo value > /etc/example, the calling shell opens the destination before sudo runs echo. The shell may lack access. This explains the failure; it is not a reason to become root for the rest of the session. Prefer a purpose-built configuration task or a carefully reviewed privileged writer for actual administration.

Environment handling also matters. A privileged program should not blindly inherit an untrusted executable search path or user-controlled configuration. Check the effective policy rather than assuming every machine preserves or removes the same variables.

Observe redirection without touching a system file

Use this harmless fixture as your regular Linux user:

study_sudo=$(mktemp -d)
printf 'before\n' > "$study_sudo/note.txt"
printf 'after\n' > "$study_sudo/note.txt"
cat "$study_sudo/note.txt"
printf 'through a writer\n' | tee "$study_sudo/note.txt"
rm -- "$study_sudo/note.txt"
rmdir "$study_sudo"

In the second command, your shell opens/truncates the file before printf runs. In the tee example, tee opens the destination. This explains why privileged administrative workflows sometimes use a reviewed sudo tee writer: the writer, not the original shell's redirection, then performs the protected open. It does not mean every failed write should be retried with sudo.

For a denied read, first decide whether the account should have access at all. If it should, fix the narrow underlying permission or policy with the appropriate administrator. For a maintenance operation that genuinely needs privilege, use the specific authorized action and check its result. Next, SSH determines how you reach the intended account; sudo concerns what that account may do afterward.

Check and revise

Is passwordless access to a shell safer merely because it is one command? No: the shell can invoke many other operations. Revision: who → as whom → exact executable and arguments → writable inputs → recovery path. Leave the VM policy unchanged in this bite.

Sources

Primary references: sudo policy reference↗; visudo↗.