<aside> 4️⃣
Module 4 — Users, Groups, and Permissions
Every file access, every command, every "Permission denied" on every Linux machine flows through one small model: who you are, what group you're in, and nine bits on an inode. Master the model and half of all production mysteries become one-line diagnoses. It is also the single most interviewed topic in Linux.
Legend used throughout: 🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start
You need Module 1 — What Linux Is, Module 2 — The Filesystem, and Module 3 — Reading and Editing Files (especially inodes and stat). This module is best experienced as a normal user who can sudo — the standard cloud/WSL setup. If whoami says root, make yourself a learner account first: useradd -m -s /bin/bash student, then passwd student, then usermod -aG sudo student, then su - student — each of these commands is explained in this module; run them now on faith, understand them by Part C. Sandbox: mkdir ~/perms.
</aside>
<aside> ℹ️
This page uses Mermaid diagram blocks. Notion shows them as code by default — click the block and set it to Preview to see the diagram. This reminder appears once per page.
</aside>
<aside> 📖
Official docs: id(1) · credentials — see intro in passwd(5)
</aside>
🧠 Linux is multi-user to its bones: every running program acts as some user, and the kernel checks every file access against that identity. Internally a user is just a number — the UID. Names like zaeem are decoration for humans; the kernel sees 1000.
One UID is special: 0, the user named root — the administrator. For UID 0 the kernel skips permission checks entirely. Not "root has all permissions" — root's requests are simply not checked. That absoluteness is why nobody works as root routinely, and why Part C's sudo exists: borrow root for one command, then put it back.
<aside> 🧩
Real-world analogy — keycards and the master key
Every hotel guest's keycard opens exactly their room. The building engineer's master key opens everything. Users are guests; root is the engineer.
Where the analogy stops working. A master key still passes through each lock. Root does not: for UID 0 the locks are not consulted at all. There is no door in the filesystem that can be locked against root — which is why "who can become root" is the actual security boundary of every Linux machine.
</aside>
🧪 Exercise A1.1 — Who are you, numerically?
whoami # your name (Module 1's old friend)
id # the full numeric truth
<aside> 📖
Official docs: group(5) · id(1)
</aside>
🧠 Giving files to users one by one does not scale, so Linux has groups: named sets of users, each with a GID. A file belongs to one user and one group, and grants a separate set of permissions to each. Real groups you have already brushed against: adm (may read logs — Module 3's /var/log files), sudo (may become root), www-data (web server processes), docker. You hold one primary group (stamped on files you create) plus any number of supplementary groups. Adding someone: sudo usermod -aG groupname username — and the -a (append) matters: without it, -G replaces the group list.
<aside> ⚠️
Trap — group changes do not apply to sessions already running. Group membership is read at login. After usermod -aG, every existing shell keeps the old list; the user must log out and back in (or start a fresh login session) before id shows the new group. "I added them to the group but it still says Permission denied" is this, roughly weekly, everywhere on earth.
</aside>
<aside> 🧩
Real-world analogy — department badges
Employees carry one badge with their department (primary group) and stickers for committees they sit on (supplementary groups). Doors admit departments and committees, not long lists of names — hire someone into Facilities and every Facilities door just works.
Where the analogy stops working. Stickers work the moment they're applied. Linux group membership is stamped onto your session at login — a new sticker does nothing for the shift you are already working. The fix is not a mystery, it is a logout.
</aside>
🧪 Exercise A2.1 — Read a colleague's reach
id root # what does the administrator's identity look like?
groups # your groups, names only — the quick version