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 chapter 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. Today’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 chapter, 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

Today’s Tools at a Glance

Category	Details
Language/Environment	Ubuntu terminal (bash shell), no internet needed
Today’s commands	`whoami` (who am I), `sudo command` (just that command as root), `sudo -i` (reside as root), `ls -l /etc/shadow` (observe a protected file)
Concepts needed	root and UID 0, sudo and sudoers, hashes, the principle of least privilege

2-1. root — The Owner of Everything

root is the special account with user number (UID) 0. When the UID is 0, the kernel (the operating system’s heart) effectively skips permission checks. Modifying system files, adding and deleting users, reading other people’s files, changing network settings — all possible.

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

This command flows like this. ① The system checks "is this user eligible to use sudo?" — only users registered in the configuration file /etc/sudoers can, and Ubuntu automatically registers the first account created during installation. ② Identity verification with my password. ③ Just that one command runs as root. ④ When it ends, you’re an ordinary user again.

You may remember from Step 21 that when using apt, nothing appeared on screen as you typed the password. That was sudo’s identity verification. Input registers even with no display, so just type and press Enter. And once verified, it doesn’t ask again for 15 minutes by default.

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.

Why store hashes? So that even if this file is stolen, the actual passwords remain unknown. Still, common passwords like "happybirthday1234" can be cracked by attacks that hash candidates one by one and compare (password cracking), so the hash list itself is not shown to just anyone. That’s why this file is protected so only root can read it, and you’ll meet it again in Level 2 when you learn password cracking.

3. Follow Along

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

(Verified 2026-09-09 on Ubuntu 24.04. Sizes and dates may differ.)

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 — the point to notice: even its owner root has only r--, meaning read-only. Nobody has write permission

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.)

How to read it: each line is one user. The long string after lee: is the hash of your password, and $6$ marks it as a SHA-512-based hash scheme. The actual password is written nowhere. Wearing root’s clothes, you crossed the permission string’s wall — this is what legitimate "privilege escalation" looks like. At the same time, you’ve just seen with your own eyes "why this hash list must never leak outside."

3-3. The sudoers File and visudo

In Section 3-2’s verification, /etc/sudoers was read-only (-r--r-----) even for root. Why guard it so hard? This file is the roster that decides "who may use sudo," and a single syntax error can paralyze sudo across the entire system.

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.)

How to read it: the prompt changes to end in #, like root@ubuntu:~#. A # prompt is a warning light saying "you are root right now." A regular user’s is $. In this state, every command runs as root without sudo.

Why it’s dangerous: in this state, one mistake like rm -rf / is irrevocable. It may look convenient, but the habit of doing everyday work while residing as root is the exact opposite of the principle of least privilege. Once you’ve confirmed it, be sure to come back:

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

The rule of judgment is simple. Work inside your home folder (/home/lee, i.e., ~) needs no sudo; work touching the outside — system areas like /etc, /var, /usr — needs sudo. Just ask, "is this file inside my house, or in a public facility?" sudo is the key to public facilities.

One bonus. If you use sudo even on files inside your home, like sudo nano ~/note.txt, that file’s owner changes to root, and you — the regular user — can no longer edit it. The principle is to use sudo only where it’s needed.

4. Missions & Exercises

Mission — Becoming a Permissions Watchdog

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"
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)
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
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 does /etc/shadow store hashes instead of actual passwords, and why is the file nonetheless locked so only root can read it?

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.

5. Model Answers & Completion Criteria

Mission Model Answer

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 ($/#)

How to verify:

① Your interpretations of the three files match the structure of Section 3-2’s verification table — passwd is 644 (everyone reads), shadow is 640+root:shadow (others blocked), sudoers is 440 (read-only even for root)
② If the log shows lines like lee : TTY=... ; COMMAND=/usr/bin/..., confirmation complete — the core point is that every sudo you use is being recorded
③ Check yourself that the paragraph includes the idea that "the blast radius of mistakes and malware stays within the account"
④ As a regular user, the prompt should end in $ and whoami should print your name

Exercise Answers

Answer 1. In order: X, O, O, X, O, X — to spell it out: ls ~ (X, viewing my house), apt update (O, refreshing system lists), cat /etc/shadow (O, a root-only file), nano note.txt (X, a file in my house), nano /etc/hosts (O, a system file, so writing requires root), mkdir ~/test (X, inside my house). There’s one criterion: "is it inside my home, or in a system area?"

Answer 2. Hashes are one-way, so even if the file is stolen, the actual passwords can’t be directly recovered. The reason it’s nonetheless locked: common passwords can be cracked by "hashing candidates and comparing," so the hash list itself is attack material.

Answer 3. Because sudo applies only to the echo, while opening the file via > is done by the original user’s (unprivileged) shell. sudo does not cover what lies beyond pipes and redirections. In such cases, use echo "x" | sudo tee /etc/some.conf.

Answer 4. Because sudo is "watched power." Who used sudo, when, and for which command — all of it remains in /var/log/auth.log. In breach investigations, the sudo records in this log are key evidence — because "traces of sudo on a hacked server" mean the attacker has already hijacked a legitimate account.

Completion Checklist

[ ] I can explain what root (UID 0) is and why it can ignore permission strings
[ ] I can demonstrate the difference between whoami and sudo whoami
[ ] I can read /etc/shadow‘s permission string and explain why it’s protected
[ ] I can explain the principle of least privilege in my own words
[ ] I know the difference between $ and # in the prompt
[ ] I confirmed that sudo usage is recorded in logs
[ ] Mission: I completed all 4 permissions-watchdog tasks

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

Today’s Concepts

Concept	One-line description
root	The supreme administrator with UID 0 — bypasses all permission checks
sudo	A temporary pass that runs "just this one command" as root — everything is logged
/etc/shadow	The vault of password hashes — readable only by root
Hash	A one-way transformation that can’t be reversed — the safe storage form of passwords
Principle of least privilege	Only as much privilege as needed, only at the moment it’s needed

Today’s Commands

Command	What it does
`whoami`	Check the current user
`sudo command`	Run just that one command as root
`sudo -i` → `exit`	Reside as root → always return
`ls -l /etc/shadow`	Observe a protected file’s permissions
`sudo rm file`	Delete a file (⚠️ unrecoverable; verify the target)

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. Click the checkbox in the sidebar to save your progress.