Step 24. Permissions 2 — Ownership and sudo: How to Wield Power

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★☆☆☆ | Estimated time: 3 hours

Prerequisites: you must have finished Step 23 (rwx permissions). An Ubuntu virtual machine (or WSL) is required.

• What you need: an Ubuntu terminal.
• Caution: today includes an experiment that reads the system area (/etc). Querying is safe, but for the file creation/deletion experiment in Section 3-5, use it only on exactly the target this unit specifies (test-write.txt).
• Note: permission queries on system files were actually run, while the outputs of commands run with sudo are marked as “output examples.”

In the last chapter, we learned “who may do what.” But one question remains. Is there no being above those rules? A being that can read every file, change every setting, delete every user.

There is. Linux has a supreme administrator account called root. Before root, Step 23’s permission strings become meaningless — even if the permissions are ----------, root reads it. The problem is that using that power in daily life is a catastrophe. This section’s topic, even before the how-to of sudo, is a first lesson in the security philosophy of “how to wield power.”

1. Learning Objectives

By the end of this unit, you will be able to:

• Explain what root (UID 0) is and why it bypasses permission checks
• Explain the order of sudo‘s operation (eligibility check → identity verification → only that command as root)
• Explain why /etc/shadow is protected, and know that what it stores is not passwords but hashes
• Explain the Principle of Least Privilege in your own words
• Judge for yourself which commands need sudo (inside my home vs. system areas)

2. Background Knowledge — Today’s Tools and Concepts

This section’s Tools at a Glance

2-1. root — The Owner of Everything

root conventionally has UID 0. Linux capabilities grant broad administrative powers over ordinary discretionary access checks. Other controls, such as mandatory access control, read-only mounts, and user namespaces, can still matter.

That’s why the root password is the key to the entire system. It’s why the ultimate goal when a hacker attacks a server is “obtaining root privileges,” and an attacker’s attempts to “somehow get their code running as UID 0” are called privilege escalation. Defenders try to block every one of those paths — this single line is the starting point of all the attack and defense techniques to come.

2-2. sudo — A Temporary Pass

sudo is short for “superuser do.” Attach it before a command and just that one command runs with root privileges:

sudo cat /etc/shadow

sudo consults configured policy, authenticates if required, then runs the command as the authorized target user, usually root. Policy can come from sudoers and included files; authentication can be cached. Ubuntu installation choices affect which users are administrators.

When sudo asks for your password, it normally displays no characters as you type. A successful authentication may be cached; the duration and whether a password is needed depend on sudo policy.

2-3. The Principle of Least Privilege

A philosophy counted among security’s first principles:

Every user and program should have only the minimum privileges necessary to do its job.

Logging in as root all the time and even surfing the web that way is like writing your bank PIN on a sticky note and attaching it to your monitor. One mistake, one piece of malware, leads straight to the destruction of the entire system. By contrast, if you live as a regular user and use sudo only when needed, the blast radius stays within “my account.” sudo is the tool for practicing this principle.

2-4. /etc/shadow — The Kingdom’s Treasure Chest

Linux user passwords are stored in the file /etc/shadow. To be precise, it’s not the passwords themselves but their one-way scrambled hashes that are stored. A hash is a function designed to be fast to compute but impossible to reverse.

A password hash is a one-way verifier rather than a recoverable plaintext password. Weak passwords may still be guessed offline, so treat hashes as sensitive. Access is normally restricted to root and authorized system components or groups.

3. Follow Along

Before you begin. UID 0 and Linux capabilities confer broad authority over ordinary permission checks, but mandatory controls, mounts, and namespaces can still limit access. sudo policy can authorize another target identity, not only root. The password prompt may be cached or disabled by policy.

3-1. Who Am I — whoami

whoami

lee

(Output example — your own account name, created when you installed Ubuntu, will appear.)

sudo whoami

root

(Output example — if this is your first sudo or 15 minutes have passed since the last use, it asks for your password first. Nothing appears on screen, but your input is being registered.)

How to read it: the same whoami, but adding sudo changed the answer to root. An experiment that lets you see with your own eyes the definition “sudo dresses a single command in root’s clothes.”

3-2. Opening a Protected File — /etc/shadow

First, as you learned in Step 23, let’s read this file’s permission strings:

ls -l /etc/passwd /etc/shadow /etc/sudoers

-rw-r--r-- 1 root root   1490 Sep  8 21:12 /etc/passwd
-rw-r----- 1 root shadow  746 Sep  8 21:12 /etc/shadow
-r--r----- 1 root root   1800 Jan 30  2024 /etc/sudoers

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read the output:

• /etc/passwd — 644. It holds the user roster, not passwords, so everyone may read it
• /etc/shadow — 640 with root shadow. Owner root has rw-, group shadow has r--, and others (including us) have --- — can do nothing
• /etc/sudoers normally has restrictive mode bits. These do not make it immutable to an appropriately privileged administrator. Use visudo for syntax-checked changes; this unit does not change sudo policy.

By the permissions, we shouldn’t be able to read shadow. Let’s confirm:

cat /etc/shadow

cat: /etc/shadow: Permission denied

(Output example.)

Make a prediction: then what happens with sudo cat /etc/shadow? Predict before running it.

sudo cat /etc/shadow

root:$6$abc...:19000:0:99999:7:::
lee:$6$xyz...:19000:0:99999:7:::
...

(Output example — actual hash values differ by system, and they are values you must never show others.)

Each shadow entry describes a local account password state and aging fields. A locked account may show a lock marker rather than a usable hash. Hash prefixes vary; $6$ identifies SHA-512 crypt, whereas newer distributions may use other schemes. Do not copy real hashes into reports.

3-3. The sudoers File and visudo

The illustrated /etc/sudoers mode is read-only by ordinary mode bits. An appropriately privileged process can still change it. Use visudo for any authorized policy edit; this lesson only inspects it.

That’s why this file is edited not directly in vim but through a dedicated tool, sudo visudo. visudo checks the syntax when you save and warns you of errors. At this stage, just remember it as “a file you don’t touch carelessly.”

3-4. Residing as root — and Why It’s Dangerous

sudo -i
whoami

root

(Output example.)

A root shell commonly displays #, but prompts are customizable. Confirm the effective identity with id -u or whoami. Exit the temporary shell as soon as the observation is complete.

A root shell can change unrelated system files with little protection against a mistaken target. Keep this exercise to identity inspection, then exit. Do not test destructive commands.

exit

3-5. Judging for Yourself Whether sudo Is Needed

Let’s learn by doing the field rule for when a command needs sudo. Try creating a file in /etc, where system settings gather:

touch /etc/test-write.txt

touch: cannot touch '/etc/test-write.txt': Permission denied

(Output example.)

sudo touch /etc/test-write.txt
ls -l /etc/test-write.txt

-rw-r--r-- 1 root root 0  Sep 9 11:05 /etc/test-write.txt

(Output example.)

How to read it: /etc is a system area regular users can’t write to. Adding sudo created it, and the owner is root.

⚠️ rm is a destructive command that deletes files beyond recovery. Linux has no recycle bin. Right now we delete only the one experiment file we just made — double-check the target path before running.

sudo rm /etc/test-write.txt

Decide whether privilege is needed from the requested operation, target permissions, and policy. A pathname inside your home is not an automatic permission grant, and a read outside it does not automatically require sudo.

Creating a new file through sudo can leave it owned by root. Editing an existing file does not invariably change ownership. Check ls -l and repair only the specific lab file if needed.

4. Missions & Exercises

Mission — Becoming a Permissions Watchdog

1. Run ls -l /etc/passwd /etc/shadow /etc/sudoers and, on paper, interpret each of the three files’ permission strings as “who can do what”
2. Run sudo cat /var/log/auth.log 2>/dev/null | grep sudo | tail -5 and confirm that the sudo commands you just used are recorded in the log (in environments without auth.log, such as WSL, try sudo journalctl 2>/dev/null | grep sudo | tail -5)
3. Write up “why residing as root is dangerous” from the perspective of the principle of least privilege in at least 5 sentences, and save it to least-privilege.txt
4. Verify firsthand two ways to tell whether you are currently root (the prompt symbol, whoami)

The answer isn’t written here — verify it in Section 5.

Exercises

Question 1. Mark O for the following commands that need sudo and X for those that don’t: ls ~, sudo apt update, cat /etc/shadow, nano note.txt, nano /etc/hosts, mkdir ~/test

Question 2. Why store password hashes rather than plaintext passwords, and why restrict access to the hashes even though they are one-way verifiers?

Question 3. sudo echo "x" > /etc/some.conf failed with “Permission denied.” Why does it fail even though sudo was attached?

Question 4. Explain, from the perspective of “logs,” why companies don’t hand out sudo privileges carelessly.

ls -l /etc/passwd /etc/shadow /etc/sudoers
sudo cat /var/log/auth.log 2>/dev/null | grep sudo | tail -5
nano least-privilege.txt   # write at least 5 sentences and save
whoami                     # check together with the prompt's last character ($/#)

6. Common Pitfalls & Fixes

Wall 1. “I ran sudo and got ‘not in the sudoers file.’”

Symptom: an error saying the user is not in the sudoers file.
Cause: this account is a user not registered on the sudo roster.
Fix: check that you logged in as the first account created during Ubuntu installation. Newly created practice accounts have no sudo privileges by default — which is actually a good lesson: “privileges are absent by default and granted deliberately.”

Wall 2. “I added sudo but still get Permission denied.”

Symptom: something like sudo echo "x" > /etc/file is refused.
Cause: the redirection trap. sudo applies only to echo; the > is handled by the original user’s shell.
Fix: use echo "x" | sudo tee /etc/file. Just remember “sudo does not cover what lies beyond pipes and redirections.”

Wall 3. “I read a post saying to use sudo su. How is that different from sudo -i?”

Symptom: every internet command collection shows a different way to become root.
Cause: sudo -i, sudo su, and sudo -s all “open a root shell,” but differ subtly in environment setup.
Fix: at this stage, whichever one it is, the essence is “you end up residing as root,” and therefore not using it routinely is the right answer. When you need root, build the habit of attaching sudo to a single command.

Wall 4. “I’m typing the password but nothing appears on screen.”

Symptom: when entering the sudo password, the cursor doesn’t move and no asterisks appear.
Cause: not a malfunction — a security feature. An old Unix tradition of not exposing even the password’s length to onlookers.
Fix: it’s normal, so just type and press Enter. If it’s wrong, it asks again.

Wall 5. “It’s my file but I can’t edit it. The owner became root.”

Symptom: ls -l shows the owner of a file in my home is root.
Cause: you created or edited a file inside your home with sudo, like sudo nano ~/note.txt.
Fix: restore the owner with sudo chown lee:lee filename. And from now on, don’t use sudo for work inside your home.

7. Summary

This section’s Concepts

This section’s Commands

More Important Than Commands: The Instinct

What you learned today is closer to an attitude than to commands. “Small privileges in daily life; big ones only when needed” — this one line is the shared habit of every professional who operates servers. Each time you use sudo, ask yourself once: “does this command truly need divine power right now?”

Remember two more things. First, facing the same door, one side studies how to guard it and the other studies how to open it — the attacker’s core research topic is “climbing from small privileges to big ones (privilege escalation),” and today you saw the door’s legitimate structure. Second, Windows’ “Run as administrator” (the UAC popup) is the same philosophy as sudo. The principle of least privilege isn’t a Linux-only story — it’s a common security language running through every operating system.

Once every box is checked, Step 24 is complete.