Step 25. User Management Lab — Crossing the Boundary Between Authentication and Authorization

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

Prerequisites: You must have finished Steps 23–24 (permissions, sudo). You need an Ubuntu VM (or WSL). This chapter includes creating and deleting test accounts.

What you need: An Ubuntu terminal and an account with sudo privileges.
Caution: Today you’ll create two test accounts (attacker and defender), and you must delete them when the lab is done. Every account is one more "open door," so leaving it around is itself a security hole.
Note: The user roster (/etc/passwd) and /etc/skel listings were verified on a live system; the outputs of the account creation, switching, and deletion commands are marked as "sample output." Every experiment in this chapter is a legal one, conducted entirely inside your own Ubuntu system.

So far, we’ve lived with just a single account. But Linux was born as "a computer shared by many people." Dozens of users log into one server with their own accounts, work in their own home folders, and are blocked from peeking at each other’s files. The permission strings from Step 23 show their real power exactly in this multi-user environment.

Today you’ll build the lab yourself. You’ll create two fake accounts — attacker and defender — and test whether the attacker can steal the defender’s secret file. This one experiment makes the sentence "permissions are the boundary of security" click in your hands, not just your head.

1. Learning Objectives

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

Explain the difference between authentication and authorization with examples
Create an account with adduser and verify its footprint in /etc/passwd
Switch to another user with su - account and explain what the hyphen (-) means
Confirm in both directions that "permissions are a defensive wall" using the 600/644 experiment
Fully clean up test accounts with deluser --remove-home

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language & environment	Ubuntu terminal (bash shell), sudo required
Today’s commands	`sudo adduser` (create account), `su - account` (switch user), `id` (show my UID/groups), `sudo deluser --remove-home` (delete account)
Concepts needed	Authentication vs. authorization, UID, home directory, /etc/passwd and /etc/skel

2-1. Authentication and Authorization — The Two Pillars of Security

Authentication: "Who are you?" — the process of verifying identity. Typing your ID and password at login is the classic example; fingerprints, OTP apps, and certificates are also authentication methods.
Authorization: "What are you allowed to do?" — the process of deciding which actions an authenticated user may perform. The permission strings from Step 23 and the sudoers roster from Step 24 are implementations of authorization.

Think of it like entering a company building. Authentication is tapping your badge at the lobby; authorization is the fact that different floors unlock depending on the clearance level printed on your badge. Even if the badge is genuine (authentication passed), the rooftop machine room door may still refuse to open (insufficient authorization).

Why does this distinction matter? Half of all security incidents come from failing to separate these two. A system built so that "once you log in, you can use every feature" falls entirely the moment one ordinary account is compromised. In contrast, a system with fine-grained authorization confines the damage to that account’s permission scope even when an account is breached.

2-2. What an Account Really Is — the UID

Inside Linux, users are managed by number, not by name. That number is the UID (User ID). The name lee is just a label for humans; the kernel knows you as "UID 1000." The numbers worth knowing:

0: root — the superuser you met in Step 24
1–999: system accounts (dedicated to services like www-data)
1000 and up: regular human accounts on Ubuntu. The first account created at install time is 1000

The user roster is stored in /etc/passwd, while password hashes live separately in /etc/shadow — in Step 24 you confirmed that only root can read shadow.

2-3. The Home Directory — Everyone’s Own Room

When an account is created, it gets a dedicated folder, /home/username. That’s the user’s "room," and the account owns it. Permissions are what keep others from barging into someone else’s room, and today’s experiment tests exactly whether that boundary can be crossed.

A new account’s room comes with basic furniture. The files stored in a treasure chest called /etc/skel are copied into the home folder when the account is created — we’ll look inside it in section 3-4.

3. Follow Along

3-1. Reading This System’s User Roster

Before creating test accounts, let’s look at what the current roster looks like. /etc/passwd is world-readable, so you don’t even need sudo:

head -3 /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin

(Verified 2026-09-09 on Ubuntu 24.04.)

How to read the output: Each line is one account, with fields separated by colons (:) — username : x (marker that the password is in shadow) : UID : group ID : description : home folder : default shell. The first line is root, UID 0. daemon (1) and bin (2) are the system accounts from section 2-2 — they’re not for logging in, so their shell is /usr/sbin/nologin.

Let’s see how many accounts there are in total and who’s at the end of the list:

wc -l /etc/passwd
tail -5 /etc/passwd

29 /etc/passwd
uuidd:x:103:103::/run/uuidd:/usr/sbin/nologin
landscape:x:104:105::/var/lib/landscape:/usr/sbin/nologin
polkitd:x:990:990:User for polkitd:/:/usr/sbin/nologin
dnsmasq:x:999:65534:dnsmasq:/var/lib/misc:/usr/sbin/nologin
tcpdump:x:105:110::/nonexistent:/usr/sbin/nologin

(Verified 2026-09-09. This environment is a minimal lab setup with no human accounts — only system accounts. On your own Ubuntu, you’ll see your account (UID 1000) at the bottom.)

How to read it: 29 lines — that is, 29 accounts, most of them system accounts. Real servers look the same: it’s normal to have far more service-dedicated accounts than human ones. Giving each service its own account is itself the principle of least privilege in action — so that even if the web server is breached, the intruder stays trapped inside www-data‘s permissions.

Let’s check whether such an account actually exists:

id www-data

uid=33(www-data) gid=33(www-data) groups=33(www-data)

(Verified 2026-09-09.)

How to read it: id shows an account’s UID, GID, and group memberships. The web-server account www-data has UID 33 — a different zone from the 1000-range human accounts.

3-2. Creating the Two Test Accounts

Now it’s time to build the lab:

sudo adduser attacker

Adding user `attacker' ...
Adding new group `attacker' (1002) ...
Adding new user `attacker' (1001) with group `attacker' ...
Creating home directory `/home/attacker' ...
Copying files from `/etc/skel' ...
New password:

(Sample output — account creation changes the system, so it wasn’t run live for this chapter. UID numbers vary by environment.)

How to read it: You can see, in order, what the system does while creating an account: assigning UID 1001, creating a dedicated group, creating the home folder /home/attacker, and copying default config files from /etc/skel. When prompted for a password, enter a simple test one (e.g., test1234!). After re-entering it, skip Full Name and the rest with Enter, and confirm with Y at the end.

Why: adduser is Ubuntu’s standard command for creating "accounts for humans." It handles the home folder, group creation, and password setup all in one go.

Create defender the same way, then verify both were registered:

sudo adduser defender
tail -2 /etc/passwd

attacker:x:1001:1002::/home/attacker:/bin/bash
defender:x:1002:1003::/home/defender:/bin/bash

(Sample output.)

How to read it: Both accounts are now on the roster. Notice how they differ from the system accounts in section 3-1 — their default shell is /bin/bash, meaning they’re human accounts that can log in.

3-3. The Defender Creates a Secret File

su - defender

(Sample output) You’ll be asked for a password. Enter the defender password you just set, and the prompt changes to defender@ubuntu:~$.

How to read it: su means "switch user." The - (hyphen) means "change the entire environment as if that user had logged in" — including moving to defender’s home folder. Without the -, only the account changes while the environment stays the same, which causes confusion, so make su - a habit.

As the defender, create a secret file and lock it:

whoami
echo "The defender's top secret: the safe code is 0426" > secret.txt
chmod 600 secret.txt
ls -l secret.txt

defender
-rw------- 1 defender defender 40  Sep  9 11:30 secret.txt

(Sample output.)

How to read it: Only the owner, defender, can read and write this file — that’s the 600 from Step 23.

3-4. Breaking In as the Attacker — The Peak of Today’s Experiment

exit
su - attacker

(exit returns you to your original account; then you switch to attacker.)

Make a prediction: What happens when attacker tries to read /home/defender/secret.txt? ① It reads. ② It’s denied. Predict first, then check.

whoami
cat /home/defender/secret.txt

attacker
cat: /home/defender/secret.txt: Permission denied

(Sample output.)

How to read it: Denied. attacker is neither the owner nor a group member, so attacker falls under "others," and in 600 the others’ permission is ---.

Why: Same computer, same disk — yet a ten-character permission string blocked the read. From the attacker’s side, how do you get over this wall? Gain higher privileges (root), hijack the defender’s account itself (an authentication attack), or wait for the defender to loosen permissions by mistake. These three are the main routes of real-world breaches.

By the way, let’s peek at what "basic furniture" got copied into the new accounts’ rooms:

ls -a /etc/skel

.
..
.bash_logout
.bashrc
.profile

(Verified 2026-09-09.)

How to read it: /etc/skel holds the files copied by default into a new account’s home — shell configs like .bashrc. When a company sysadmin wants to plant common settings into every employee account, this is where they make the change.

3-5. Loosen the Permission, and the Door Opens

Let’s reproduce the situation where the defender loosens the permission by mistake:

exit
su - defender
chmod 644 secret.txt
exit
su - attacker
cat /home/defender/secret.txt

The defender's top secret: the safe code is 0426

(Sample output.)

How to read it: Once defender changed it to 644 (granting read to others), attacker could read it. The file’s contents didn’t change one bit, but a few characters of a string split "secret" from "public." You’ve now confirmed in both directions that a permission misconfiguration is itself a security incident — blocked at 600, breached at 644.

3-6. Cleanup — Tearing Down the Lab

⚠️ deluser deletes an account from the system, and --remove-home wipes that account’s entire home folder too. It cannot be undone. For now, delete only the two test accounts you made today — double-check the account names before running.

exit
sudo deluser --remove-home attacker
sudo deluser --remove-home defender
ls /home

Removing user `attacker' ...
...
lee

(Sample output.)

How to read it: Both test accounts and their home folders are gone, and only your original account remains in /home.

Why: Cleaning up the environment after an experiment is part of the craft. It’s the same logic as when someone leaves a company and IT’s very first move is to lock that person’s account — as long as an account lives, anyone who knows its password can still open the door. Incidents that began with "an account that was never deactivated after departure" show up again and again in the statistics. Today’s cleanup isn’t tedious dishwashing; it’s a miniature of enterprise security operations.

4. Missions & Exercises

Mission — Write a Permission Boundary Report

Find your own account’s line in /etc/passwd, check its UID and home folder, and compare them with the output of id
Use ls -a /etc/skel to see which files are copied by default into a new account (seeing .bashrc means it’s normal)
Write up today’s four scenes — ① defender locks with 600 ② attacker’s read is denied ③ permission loosened to 644 ④ attacker’s read succeeds — one paragraph each from an "authorization perspective," and save them in authz-report.txt
After deleting the test accounts, verify the cleanup is perfect by checking that grep -c attacker /etc/passwd returns 0 (if it isn’t 0, hunt down what’s left)

No answers here — you’ll verify them in section 5.

Exercises

Question 1. Sort the following into authentication and authorization: ① tapping an access badge ② the archive room door opens only at my clearance level ③ passport check at the airport ④ lounge access by airplane seat class

Question 2. What’s the difference between su defender and su - defender, and why should the latter be your habit?

Question 3. You switched to attacker, but defender’s 600 file read just fine. Is the experiment broken? What’s the first thing you should suspect and check?

Question 4. A server administrator discovers an unfamiliar account registered in /etc/passwd. Explain why this is a strong signal of compromise, connecting it to today’s experiment.

5. Model Answers & Completion Criteria

Mission Model Answer

grep "^lee" /etc/passwd      # my account's line (use your own username)
id
ls -a /etc/skel
nano authz-report.txt        # write the four scenes from an authorization perspective
sudo deluser --remove-home attacker
sudo deluser --remove-home defender
grep -c attacker /etc/passwd

(The last output is a sample — it’s 0 if the account was fully deleted.)

How to verify: ① The UID of your line in /etc/passwd (usually 1000) must match the uid in the id output. ② Confirm .bashrc. ③ Check that each paragraph of the report contains phrasing like "authorization (permissions) decided the allow/deny" — it must not get mixed up with authentication (login). ④ If the final grep -c is 0, cleanup is complete. As a reminder from the live capture in section 3-1, each /etc/passwd line has the format account:x:UID:GID:description:home:shell.

Exercise Solutions

Question 1 solution. Authentication is ①③ (identity verification); authorization is ②④ (allowing actions based on the verified identity). A badge and a passport "prove who I am," while the door’s clearance level and lounge access are "what the proven me is allowed to do."

Question 2 solution. The - (hyphen) means a "login shell" — environment variables and the working directory all change as if that user had logged in. Without the hyphen, only the account changes while the environment stays the previous user’s, so paths and settings get tangled. That’s why you use su - by habit.

Question 3 solution. The experiment isn’t broken; in most cases the experimental conditions got contaminated. You habitually typed sudo cat (reading as root obviously succeeds), or you’re actually still defender or your original account. Before any experiment, always check "who am I right now" with whoami — the fairness of an experiment starts there.

Question 4 solution. After a successful intrusion, attackers often secretly create their own account "so they can come back next time" — the very same motion you used to create attacker today. That’s why an unknown account is a strong signal of compromise, and why reviewing the account roster is a basic item in any server security check. Closing and verifying doors matters even more than opening them.

Completion Criteria Checklist

[ ] I can explain the difference between authentication and authorization with examples
[ ] I can read the fields of a /etc/passwd line (account, UID, home, shell)
[ ] I can create an account with adduser and clean it up with deluser –remove-home
[ ] I can explain what the hyphen in su - means
[ ] I can explain the role of /etc/skel
[ ] I felt, through the 600/644 experiment, that permissions are a defensive wall
[ ] Mission: I completed the permission boundary report and the leftover check (grep -c = 0)

6. Common Pitfalls & Fixes

Wall 1. "What’s the Full Name that adduser is asking for?"

Symptom: While creating an account, you’re asked for Full Name, Room Number, and so on, and it’s confusing.
Cause: A legacy from the era of office phone directories — every one of these fields is optional.
Fix: Just press Enter to skip them all. The account is created fine even if they’re blank.

Wall 2. "I ran su – defender and got a weird error."

Symptom: An error appears right after switching, or you end up somewhere other than the home folder.
Cause: You often forgot the - on su. The environment variables remain the previous user’s, so things get tangled.
Fix: Come back out with exit, then switch with the hyphen attached, like su - defender. A single hyphen decides whether it’s a "login shell."

Wall 3. "I’m attacker, but defender’s file still reads!"

Symptom: The file is chmod 600, yet cat succeeds.
Cause: Most of the time you attached sudo out of habit, or you’re actually in a different account. With sudo cat you’re reading as root, so of course it reads.
Fix: Before experimenting, always check the current account with whoami.

Wall 4. "I deleted with deluser, but the folder is still in /home."

Symptom: The account is gone, but its home folder remains.
Cause: You omitted the --remove-home option, files owned by someone else are mixed into the home folder, or processes were still running as that account at deletion time — any of these can make cleanup fail.
Fix: Check for leftover processes with ps aux | grep username. If manual cleanup is needed, use sudo rm -r /home/username — but remember, rm -r deletes a folder beyond recovery — verify three times that it really belongs to the test account before deleting. In real operations too, "verify after deleting" is part of the procedure.

7. Summary

Today’s Concepts

Concept	One-line description
Authentication	"Who are you?" — identity verification (login)
Authorization	"What may you do?" — deciding allowed actions (permission strings, sudoers)
UID	A user’s internal number — 0 is root, 1000+ are human accounts
Home directory	The account’s private room — /home/username
/etc/skel	The storage box of default furniture copied into a new account’s room

Today’s Commands

Command	What it does
`sudo adduser name`	Create a human account (home, group, and password included)
`su - account`	Switch user (hyphen = login shell)
`id`	Check my UID and groups
`head`/`tail /etc/passwd`	Read the user roster
`sudo deluser --remove-home name`	Delete account + home (⚠️ unrecoverable; always confirm the name)

The Instinct That Matters More Than Commands

Linux security, in substance, is "file permissions" (Step 23) meshing with "human boundaries" (today) and turning together. Someone who understands the principle can ask the same questions on any unfamiliar system: "Who owns this file? Who can read it? What is this account allowed to do?"

Authentication and authorization — these two words are the coordinate axes that run through the entire security industry. "MFA (multi-factor authentication)" in a login system is authentication hardening; "RBAC (role-based access control)" and cloud IAM are systematized authorization. The stock sentence of breach reports — "the attacker hijacked a legitimate account and penetrated the internal network" — means they bypassed the door of authentication and then operated within that account’s authorization scope. Authentication is the verification of identity; authorization is the permission of action. With this one definition, countless security articles will start to make sense.

Once every box is checked, Step 25 is complete. Click the checkbox in the sidebar to save your progress.