Module 4 — Users, Groups, and Permissions
Updated 2 September 2026
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)
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.
Part A — Identity: users, groups, and the two account files
A1. Users, and the one called root
🧠 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.
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.
🧪 Exercise A1.1 — Who are you, numerically?
whoami # your name (Module 1's old friend)
id # the full numeric truth✅ Expected result — click to reveal
zaeem
uid=1000(zaeem) gid=1000(zaeem) groups=1000(zaeem),4(adm),27(sudo),100(users)What to read out of it (names and numbers vary with your setup):
- uid=1000(zaeem) — your number, with your name in brackets. First regular users on most distros start at 1000; numbers below that belong to the system.
- gid=1000(zaeem) — your primary group (next section). Ubuntu makes a personal group per user, same name, same number.
- groups=... — every group you belong to. Spot 27(sudo) if present: membership in that group is what lets you become root on Ubuntu. This one line answers "what could this account touch?" — which is why id someuser is the first command of every access investigation.
A2. Groups — permissions for teams
🧠 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.
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.
🧪 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✅ Expected result — click to reveal
uid=0(root) gid=0(root) groups=0(root)
zaeem adm sudo usersWhat to read out of it:
- Root is UID 0, GID 0, and typically belongs only to its own group — it needs no others, because checks don't apply to it. Sparse by design.
- groups is id minus the numbers: quicker to read aloud on a call. Both read the same membership data.
A3. /etc/passwd — the account register
🧠 Accounts live in a plain text file — /etc/passwd — one line per account, seven fields separated by colons:
name : x : UID : GID : comment : home : shellEverything Module 2 and this module taught snaps together in one line of it: the UID, the primary GID, the home directory, and the login shell (Module 1's $SHELL) all come from here.
The laminated staff directory lists everyone's name, employee number, department, and office — public inside the building, because the building runs on people looking each other up. What it pointedly does not list: anyone's safe combination.
Where the analogy stops working. A lobby directory is curated by HR weekly. /etc/passwd is the authoritative database, live — programs consult it on every uid-to-name translation, and editing it carelessly (there is a special editor, vipw, that guards against this) can lock every user out at once.
🧪 Exercise A3.1 — Read your own row
head -3 /etc/passwd # the first three accounts
grep "^$(whoami):" /etc/passwd # your row ($(...) runs whoami and pastes its output — Module 5 formalizes this)✅ Expected result — click to reveal
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
zaeem:x:1000:1000:Zaeem:/home/zaeem:/bin/bashWhat to read out of it:
- Root's row, decoded left to right: name root, x (hash elsewhere), UID 0, GID 0, comment, home /root (Module 2's naming trap), shell bash.
- daemon and bin are system accounts — services run as these so a hacked service isn't a hacked machine. Their "shell" is /usr/sbin/nologin, a program whose only job is to refuse logins: an account that can own things but never be logged into.
- Your own row ties the whole Foundation together: that home directory is where Module 2 started you; that shell is what Module 1 introduced.
A4. /etc/shadow — where the secrets actually live
🧠 Password hashes live in /etc/shadow: one row per account — name, the password hash (never the password itself), and password-ageing bookkeeping. Its permissions are the lesson: readable only by root and the shadow group. A hash cannot be reversed into the password, but it can be attacked by bulk guessing — so even hashes are locked away.
🧪 Exercise A4.1 — Bounce off the lock (fails on purpose)
cat /etc/shadow # as a normal user
ls -l /etc/shadow # and inspect why✅ Expected result — an error, on purpose — click to reveal
cat: /etc/shadow: Permission denied
-rw-r----- 1 root shadow 652 May 8 16:30 /etc/shadowWhat to read out of it:
- Your first honest Permission denied of the module — and unlike Module 2's No such file or directory, the file exists; you specifically may not read it. Different error, different meaning, different fix.
- The ls -l row explains the refusal, and by the end of Part B you will read it fluently: owner root may read/write, group shadow may read, everyone else — the trailing --- — nothing. You are in "everyone else".
- Preview of Part D: how does the passwd command let you change your own row in a file you cannot even read? Hold that thought.
Part A — Interview questions
🎯 "What is the root user?" — asked verbatim in GeeksforGeeks' Linux Interview Questions (70+ questions, updated July 2026)
The superuser: UID 0, for which the kernel bypasses permission checks entirely. Root can read, change, or delete anything, change any identity, and reconfigure the system — which is why direct root logins are disabled on well-run systems and administration flows through sudo: per-command elevation, with an audit log, revocable per user.
The details that separate candidates: "checks are skipped, not passed" — the precise mechanism; that root's power is why it's rarely used interactively (blast radius, no audit trail, no undo); and knowing UID 0 is what matters, not the name "root" — a second UID-0 account is a classic backdoor to look for.
🎯 "What is the difference between a user and a group?" — asked verbatim in GeeksforGeeks' Linux Interview Questions (70+ questions, updated July 2026)
A user is an identity that processes run as — a UID with a name, home, and shell. A group is a named set of users — a GID — existing so permissions can be granted to teams rather than person-by-person. Every file has exactly one owning user and one owning group with separate permission sets; every user has one primary group (stamped on files they create) plus supplementary groups joined via usermod -aG.
The details that separate candidates: primary versus supplementary, and which one lands on new files; the login-time snapshot trap (new membership needs a re-login); and a concrete example — "add deployers to www-data instead of chmodding the web root open".
🎯 "What is the difference between /etc/passwd and /etc/shadow?" — asked verbatim in GeeksforGeeks' Linux Interview Questions (70+ questions, updated July 2026)
/etc/passwd: the world-readable account database — name, UID, GID, home, shell; the x marks the password's absence. /etc/shadow: root-only (plus group shadow), holding the password hashes and ageing policy. Split because the system constantly needs uid↔name lookups (so passwd must stay readable), while hashes must be hidden even from users — world-readable hashes were how 1980s Unix passwords got cracked.
The details that separate candidates: explaining why passwd must remain world-readable (every ls -l does a lookup); hashes-not-passwords; and the file-permission proof — quoting -rw-r----- root shadow from memory shows you have actually looked.
Part B — The permission model
B1. Reading the ten characters
🧠 Module 2 taught you to read ls -l's first character (file type). Now the other nine: three triplets of rwx, for the file's user (owner), group, and others — in that order, always.
- rw- r-- ---
│ │ │ └─ others: nothing
│ │ └─ group: read only
│ └─ owner: read + write
└─ regular fileFor a file: r read the contents, w change the contents, x execute it as a program. A - means that right is absent.
The kernel's checking algorithm is rigid and worth knowing exactly: if your UID owns the file, the owner triplet applies — and only that triplet; else if one of your groups owns it, the group triplet applies; else the others triplet. First match wins, no fallthrough, no accumulating:
Diagram source
flowchart TD
A["Access request<br>(not root)"] --> B{"Am I the owner?"}
B -->|"yes"| C["Owner bits apply<br>— and ONLY these"]
B -->|"no"| D{"In the owning group?"}
D -->|"yes"| E["Group bits apply"]
D -->|"no"| F["Others bits apply"]Every file wears a door sign with three lines: "the owner may: …", "the department may: …", "everyone else may: …". Security reads only the first line that describes you and turns you away or waves you through on that line alone.
Where the analogy stops working. Human security would use common sense when the sign is self-contradictory ("the owner may nothing, everyone else may enter"). The kernel executes the sign literally — which, oddly, is a feature: literal rules can be audited, reasoned about, and fixed; common sense cannot.
🧪 Exercise B1.1 — Read three real signs
ls -l /etc/os-release /etc/shadow /usr/bin/passwd✅ Expected result — click to reveal
lrwxrwxrwx 1 root root 21 Feb 6 2026 /etc/os-release -> ../usr/lib/os-release
-rw-r----- 1 root shadow 652 May 8 16:30 /etc/shadow
-rwsr-xr-x 1 root root 64152 May 30 2024 /usr/bin/passwdWhat to read out of it:
- The symlink shows rwxrwxrwx — link permissions are decoration; what counts is the target's (Module 3's arrow, now with its permission footnote).
- /etc/shadow, fluently: regular file; owner root reads and writes; group shadow reads; others nothing. Exactly what A4.1 experienced from the outside.
- /usr/bin/passwd contains a letter that is not in your alphabet yet: s where owner-x should be. Part D. Patience.
B2. rwx on directories — the different trio
🧠 On a directory, the same three letters mean different things, because a directory (Module 3) is a list of name→inode entries:
- r — read the list: you may ls the names.
- w — edit the list: create, rename, and delete entries in it.
- x — pass through: enter it with cd, and reach anything by a path that traverses it.
They combine into real personalities: r without x = you may see the names but reach nothing; x without r = you may reach things whose names you already know, but ls is refused — a deliberate design for "use, don't browse" directories.
A directory is a room whose contents are found via an index-card box by the door. r lets you flip through the cards, x lets you walk in, w lets you add and remove cards. Removing a card is how a thing stops existing here — nobody touches the thing itself.
Where the analogy stops working. In a real room, removing the card leaves the object on the shelf for anyone to stumble on. In Linux, removing the last card (link count zero, no open handles — Module 3) makes the object itself cease to exist. The card is the object's grip on existence.
🧪 Exercise B2.1 — Delete a file you cannot read (the point is that it works)
cd ~/perms
touch secret.txt
chmod 000 secret.txt # no permissions at all, for anyone (chmod syntax: next section)
cat secret.txt # denied, naturally
rm secret.txt # and yet...
ls✅ Expected result — click to reveal
cat: secret.txt: Permission denied
rm: remove write-protected regular empty file 'secret.txt'?— answer y, and the final ls shows it gone.
What to read out of it:
- The read was refused by secret.txt's own mode (000). The delete succeeded because it never consulted that mode — only your w on ~/perms, which you have.
- rm's question is a courtesy, not a check: rm noticed the file was write-protected and asked politely (add -f and it wouldn't). The kernel would have permitted the unlink either way.
- Say the rule once, aloud: file permissions protect content; directory permissions protect existence.
B3. chmod, symbolic — editing rights like text
🧠 chmod (change mode) speaks two languages. The symbolic one reads like edits: who (u, g, o, or a for all) operator (+ add, - remove, = set exactly) what (r, w, x). Comma-join multiple edits: chmod u+w,go-r file. Symbolic is relative — it touches only the bits you name, leaving the rest alone, which makes it the safe choice for "add one right without disturbing anything".
🧪 Exercise B3.1 — Sculpt a file's sign
cd ~/perms
touch report.txt
ls -l report.txt # the default birth permissions (B5 explains where they come from)
chmod go-rw report.txt # strip read AND write from group and others
ls -l report.txt
chmod u+x report.txt # add execute for owner
ls -l report.txt✅ Expected result — click to reveal
-rw-rw-r-- 1 zaeem zaeem 0 Sep 2 15:46 report.txt
-rw------- 1 zaeem zaeem 0 Sep 2 15:46 report.txt
-rwx------ 1 zaeem zaeem 0 Sep 2 15:46 report.txtWhat to read out of it:
- Line by line, only the named bits moved: go-rw blanked group's and others' read and write; u+x set one bit. Everything else — untouched. That is symbolic mode's contract. (Why strip w too? On Ubuntu your files are born group-writable — B5 explains.)
- -rw------- is the standard shape for private files (SSH keys, Module 15, will demand it). -rwx------ is the standard shape for personal scripts.
B4. chmod, numeric — the octal dial
🧠 The numeric language encodes each triplet as one digit: r=4, w=2, x=1, added together. rwx=7, rw-=6, r-x=5, r--=4, ---=0. Three digits, owner-group-others: chmod 640 file is rw-r-----. Numeric mode is absolute — it sets all nine bits at once, ignoring what was there. Perfect when you know the exact end state; hazardous as a lazy reflex, because it silently erases bits you forgot were set. The canon worth memorizing: 644 files, 755 directories and programs, 600/700 private things, 640/750 group-shared things.
The numeric mode is a lock with three dials, one per audience, each dial a sum of read-4, write-2, execute-1. Setting the lock means dialing all three to chosen numbers — whatever they showed before is gone.
Where the analogy stops working. Dials you can read before turning. Engineers using numeric chmod routinely don't look first — symbolic mode edits ("just add group read") exist precisely because setting-by-overwriting punishes inattention.
🧪 Exercise B4.1 — Same file, spoken in numbers
cd ~/perms
chmod 640 report.txt
ls -l report.txt
chmod 754 report.txt
ls -l report.txt
stat -c '%a %A %n' report.txt # stat can speak both languages at once✅ Expected result — click to reveal
-rw-r----- 1 zaeem zaeem 0 Sep 2 15:46 report.txt
-rwxr-xr-- 1 zaeem zaeem 0 Sep 2 15:46 report.txt
754 -rwxr-xr-- report.txtWhat to read out of it:
- Decode both directions until instant: 640 → rw- / r-- / ---; rwxr-xr-- → 754. Interviewers time this, informally.
- The stat line is your translation cross-check tool: octal and letters, side by side, plus the name.
B5. umask — where default permissions come from
🧠 B3.1's fresh file was born rw-rw-r-- — who decided? Programs request generous modes at creation (666 for files, 777 for directories), and the umask — a per-process value — clears chosen bits before the mode is applied. The classic default 022 clears group-write and others-write: 666 → 644, 777 → 755. But standard Ubuntu user logins use 002: Ubuntu gives each user a private group containing only them (A1.1's matching uid/gid), so keeping group-write is safe — files arrive 664, directories 775. A stricter 027 yields 640/750 — and note it is a mask, not subtraction: 027 against a 666 request gives 640, not the 637 subtraction would predict, because a bit already absent cannot be removed again. Check yours with umask; set it for a session with umask 027; make it permanent in your shell's startup file (Module 3's .bashrc).
Programs roll out generous dough (666/777); the umask is a cutter that stamps away the parts your policy forbids. Every new cookie in this kitchen automatically has the same bite taken out.
Where the analogy stops working. A cutter shapes only what passes through it — and nothing can add dough that was never rolled. Umask is subtractive-only by design; when you need a new file to be more open than the masked default, that is a chmod after the fact, visible and auditable.
🧪 Exercise B5.1 — Watch the mask at work
umask # your current mask, in octal
touch masked.txt
mkdir maskeddir
ls -ld masked.txt maskeddir # -d: show the directory itself, not its contents✅ Expected result — click to reveal
0002
drwxrwxr-x 2 zaeem zaeem 4096 Sep 2 15:46 maskeddir
-rw-rw-r-- 1 zaeem zaeem 0 Sep 2 15:46 masked.txtWhat to read out of it:
- 0002 (the leading 0 is a fourth digit for Part D's special bits): only others lose w — Ubuntu's private-group default. Running as root, or on most other distros, expect 0022 and correspondingly stricter births.
- The mask, verified live: file request 666, masked to 664 (rw-rw-r--); directory request 777, masked to 775 (drwxrwxr-x) — directories keep x because they are requested with it (you must be able to enter what you create).
- Try umask 077; touch private.txt; ls -l private.txt — born rw-------. Session-only; new terminals reset to the default.
Part B — Interview questions
🎯 "What are Linux file permissions?" — asked verbatim in GeeksforGeeks' Linux Interview Questions (70+ questions, updated July 2026); InterviewBit (2025) words it "What are file permissions in Linux?"
Nine bits per inode, three triplets — owner, group, others — each granting read, write, execute. On files: read/change content, run as program. On directories the same letters govern the name list: ls it, modify it (create/rename/delete entries), traverse it. The kernel applies the first matching triplet only (owner, else group, else others), and skips checks entirely for root. Displayed by ls -l, changed by chmod, defaulted by umask, owned via chown/chgrp.
The details that separate candidates: first-match-wins (no accumulation); the directory reinterpretation, especially deletion needing directory-w rather than file-w; and mentioning where the bits live — the inode, tying Module 3 to this one.
🎯 "What do the permissions rwxr-xr-- mean?" — asked verbatim in GeeksforGeeks' Linux Interview Questions (70+ questions, updated July 2026)
Owner: read, write, execute. Group: read and execute, no write. Others: read only. Numerically 754. Typical for a script the owner maintains, teammates may run, and the world may only inspect.
The details that separate candidates: giving the octal instantly (shows fluency both directions); noting that for a script others' r-without-x means they can read the code but not execute it directly — though nothing stops them running bash script on a file they can read, which is why read permission on scripts is effective execute for the determined; that nuance lands very well.
🎯 "What do you mean by unmask?" — asked verbatim (typo included) in InterviewBit's Linux Interview Questions (2025); Turing's 100+ set (2025) asks it as umask, "used to determine the default permissions for newly created files and directories"
The user file-creation mask: an octal bit-mask cleared from the mode a program requests at creation time (666 files, 777 directories). Umask 022 yields 644/755; 027 yields 640/750 (masking, not subtraction); 077 yields 600/700; Ubuntu's private-user-group logins default to 002, yielding 664/775. Set per session with umask NNN, persistently in shell startup files or login configuration. It can only remove bits — never add — which is why new files are never born executable.
The details that separate candidates: the mask-from-request mechanism (candidates who say "umask sets default permissions" have the direction wrong); the files-never-executable consequence; and — worth a smile in the room — knowing the question's "unmask" spelling is a typo that has propagated through interview prep sites for years.
Part C — Ownership, and borrowing power
C1. chown and chgrp — reassigning files
🧠 chown newowner file changes a file's owning user; chown newowner:newgroup file changes both at once; chgrp newgroup file changes just the group. -R recurses through a directory tree — with the same reach, and the same need for care, as every other -R you have met.
The rule that surprises everyone: only root can chown. A normal user cannot give their own file away — not even a file they fully own. (Reasoning: gifted files would let users dodge disk quotas and plant files "owned" by victims.) Changing a file's group is allowed without root, but only to a group you belong to.
Repainting your car (chmod) is your business. Transferring the title (chown) goes through the licensing office — an authority validates the transfer, because titles determine liability, tax, and insurance. File ownership determines quota, audit, and blame; same logic.
Where the analogy stops working. The licensing office serves any legitimate seller. Linux's office serves only root — the file's current owner has no title-transfer counter at all. It is one of the few things ownership does not let you do with your own property.
🧪 Exercise C1.1 — Try to give a file away (fails on purpose, then succeeds properly)
cd ~/perms
touch giveaway.txt
chown root giveaway.txt # as yourself: donate it to root
sudo chown root giveaway.txt # now with borrowed authority (sudo: next section)
ls -l giveaway.txt
sudo chown $(whoami) giveaway.txt # take it back before moving on✅ Expected result — an error, on purpose — click to reveal
chown: changing ownership of 'giveaway.txt': Operation not permitted
-rw-rw-r-- 1 root zaeem 0 Sep 2 15:52 giveaway.txtWhat to read out of it:
- Operation not permitted — the third distinct refusal in your collection, and the rarest: not a missing path, not a permission bit, but a rule of the kernel itself. No chmod can fix it; only identity (root) satisfies it.
- After the sudo version: owner root, group still yours — chown with a bare name changes the user only.
- If the sudo line asked for a password: that is your own password, not root's — the mechanism explained next.
C2. sudo — root, one command at a time
🧠 sudo command runs one command as root (verify anytime: sudo whoami → root). The design, piece by piece: you authenticate with your own password (root's may not even exist — Ubuntu ships root's password locked); authorization comes from /etc/sudoers — on Ubuntu, membership in the sudo group grants full rights, but sudoers can equally grant specific commands to specific users ("deployers may restart nginx, nothing else"); every use is logged with who, what, and when; and a grace period (15 minutes on Ubuntu; upstream sudo's own default is 5 — timestamp_timeout in sudoers) lets consecutive sudos skip re-typing the password. Edit sudoers only via sudo visudo — it syntax-checks before saving, because a broken sudoers locks everyone out of root.
Why this beats logging in as root: no shared root password to leak or rotate, per-person audit trails, per-command granularity, and the habit-forming friction of typing sudo — a deliberate speed bump before every dangerous act.
The master key lives in a lockbox at reception. Any authorized engineer can sign it out — with their own badge, for one job, and the logbook records who had it when the penthouse door turned up scratched. Nobody carries it home.
Where the analogy stops working. A signed-out key opens everything until returned; sudo's grant is per command — the key teleports back into the box after each use. And unlike a lockbox, sudoers can issue keys that only open specific doors: "may restart the web server" is a grantable key with no physical equivalent.
🧪 Exercise C2.1 — Borrow, verify, observe the ledger
whoami
sudo whoami # same terminal, different identity for one command
sudo tail -3 /var/log/auth.log # the ledger itself: your sudo, logged (path may be /var/log/secure on RHEL family)✅ Expected result — click to reveal
zaeem
root
2026-09-02T15:53:01.123456+00:00 myhost sudo: zaeem : TTY=pts/0 ; PWD=/home/zaeem/perms ; USER=root ; COMMAND=/usr/bin/whoami
...What to read out of it:
- The pair of whoamis is the entire concept in two lines: identity is per-command, not per-terminal.
- The log line names you, your terminal, your working directory, the identity you assumed, and the exact command. In an incident review, these lines reconstruct who did what — one reason teams ban shared root logins, which record nothing about the human behind them.
- If your account lacks sudo rights you'll see zaeem is not in the sudoers file — itself logged, as an attempt.
C3. su and sudo -i — becoming someone for longer
🧠 For a stretch of privileged work, opening a whole shell as another identity beats prefixing thirty commands: sudo -i — a root login shell, authenticated by your password, logged; leave with exit. sudo -u someuser command runs a command as any user, not just root — the practical tool for "would the app's account be able to read this?": sudo -u www-data cat /etc/app/secret.conf answers the question as the app. Classic su - someuser switches identity too, but demands the target's password — mostly superseded by sudo everywhere that sudo is configured.
🧪 Exercise C3.1 — Answer a permissions question as someone else
cd ~/perms
chmod 600 report.txt # owner-only
sudo -u nobody cat report.txt # can the unprivileged 'nobody' account read it?
chmod 644 report.txt
sudo -u nobody cat report.txt # and now?✅ Expected result — first half fails, on purpose — click to reveal
cat: report.txt: Permission deniedthen, after opening it up — the file's contents (empty here, so: nothing, silently — the exit was success).
What to read out of it:
- You just tested a permission hypothesis instead of reasoning about it — the difference between "should work" and "verified". sudo -u is the standard tool for reproducing a service's Permission denied without touching the service.
- nobody is a stock minimal-privilege account (see it in /etc/passwd) — historically what services dropped to; handy today as a stand-in for "least privileged possible reader".
- Note the empty-file subtlety in the second run: success printed nothing. Module 1's silence rule keeps paying rent.
Part C — Interview questions
🎯 "What is the difference between chmod and chown?" — asked verbatim in GeeksforGeeks' Linux Interview Questions (70+ questions, updated July 2026)
chmod changes a file's permission bits — what the owner, group, and others may do. chown changes who the owner and group are: chown user:group file. Different axes of the same model: chown decides which triplet applies to whom; chmod decides what each triplet contains. Owners may chmod their own files; chown requires root (group changes excepted, within your own groups).
The details that separate candidates: the two-axes framing; the only-root-can-chown rule with its quota/blame rationale; and the operational pairing — most real fixes are a chown to the right group plus a group-bit chmod, not a wider chmod.
🎯 "Explain about the chown command?" — asked verbatim in Turing's 100+ Linux interview questions (2025), alongside its chmod twin
chown reassigns ownership: chown alice file (user), chown alice:developers file (user and group), chown :developers file or chgrp developers file (group only), -R for trees. Root-only for the user part. The everyday use in DevOps is aligning deployed files with the service account that must read them — chown -R www-data:www-data /var/www/app after a deploy.
The details that separate candidates: the colon syntax variants; knowing -R on a tree with symlinks deserves care (chown follows or not depending on flags — -h affects the link itself); and framing chown as the deployment tool it is, not an obscure admin command.
Part D — The special bits
D1. The execute bit in practice — your first script
🧠 Time to cash in B5's promise: files are never born executable, so making something runnable is always an explicit act. The three-step birth of every script you will ever write: create it, chmod +x it, run it as ./name (the ./ says "this one, here" — Module 5 explains why the shell will not find it by bare name).
🧪 Exercise D1.1 — Permission denied, then not (first run fails on purpose)
cd ~/perms
echo 'echo hello from my first script' > hello.sh
ls -l hello.sh
./hello.sh # run it — refused
chmod +x hello.sh
./hello.sh # and now✅ Expected result — an error, on purpose — click to reveal
-rw-rw-r-- 1 zaeem zaeem 32 Sep 2 15:55 hello.sh
bash: ./hello.sh: Permission denied
hello from my first scriptWhat to read out of it:
- The refusal came from the missing x — the file was readable, even writable, but not runnable. One chmod +x later, it is a program.
- Collection update — you now hold all three classic refusals and their meanings: No such file or directory (path wrong, or dangling link), Permission denied (a permission bit said no), Operation not permitted (a kernel rule said no). Diagnosing which family an error belongs to is the first fork in every troubleshooting tree.
- This tiny file is the seed of Module 10; the shebang line that professional scripts start with is taught there.
D2. setuid and setgid — programs that outrank their users
🧠 A4 left a puzzle: passwd lets you edit your row in /etc/shadow, a file you cannot read. The mechanism is the setuid bit: a program file marked setuid runs as its owner, not as its caller. /usr/bin/passwd is owned by root and marked setuid — shown as s in the owner-execute slot: -rwsr-xr-x. Run it, and for that one process you are root — but only inside a program whose code decides exactly what you may do (change your own password; nothing else). setgid is the same idea for the group; on directories it does something different and useful: new files inside inherit the directory's group — the standard trick for shared team folders. Octal: setuid 4, setgid 2, as a fourth leading digit (chmod 4755, chmod 2775).
You cannot walk into the records room, but the clerk at the counter can — and will update your record for you, following the office's procedures exactly. passwd is a clerk: you hand over a request; the clerk, with their room key, performs the one sanctioned change.
Where the analogy stops working. A dishonest customer cannot become the clerk. With setuid, the caller's process is the clerk for the program's duration — so a flaw in the clerk's procedures (a bug) lets the customer act with the clerk's full authority anywhere in the room. Software clerks must be provably incorruptible; hence: few, small, audited.
🧪 Exercise D2.1 — Spot the s
ls -l /usr/bin/passwd /usr/bin/sudo
ls -ld /var/local # a setgid directory shipped on stock Ubuntu✅ Expected result — click to reveal
-rwsr-xr-x 1 root root 64152 May 30 2024 /usr/bin/passwd
-rwsr-xr-x 1 root root 277936 Apr 8 2024 /usr/bin/sudoand /var/local showing drwxrwsr-x ... root staff — the s sitting in the group-execute slot.
What to read out of it:
- sudo itself is setuid root — of course it is: it must become root in order to lend root. The entire Part C mechanism rests on this Part D bit.
- Lowercase s = bit set and underlying x present; a capital S would mean the bit is set but x is missing — almost always a misconfiguration, worth flagging when you see it.
- Finding all setuid programs on a box is a standard security sweep; the tool for such searches (find) headlines Module 6.
D3. The sticky bit — shared spaces without theft
🧠 B2 established that write on a directory means "may delete any entry in it". Then how can /tmp — writable by everyone — work at all? Why can't users delete each other's temp files? The sticky bit: set on a directory, it restricts deletion and renaming of entries to the entry's owner (and the directory's owner, and root), even for users with directory-write. Shown as t in the others-execute slot: /tmp is drwxrwxrwt, octal 1777.
A coat rack by the door: anyone may hang a coat (world-writable), and social order demands you take only your own. The sticky bit is the attendant who enforces it — hang freely; remove only what is yours.
Where the analogy stops working. The attendant recognizes faces and makes exceptions for good stories. The kernel checks exactly three identities — entry owner, directory owner, root — and hears no stories. Also, the name: "sticky" described a long-obsolete memory behaviour on 1970s Unix; the modern meaning kept the name and dropped the meaning. Expect the interviewer to enjoy that fossil.
🧪 Exercise D3.1 — Read the t, then bounce off it (second half fails on purpose)
ls -ld /tmp
touch /tmp/mine.txt # your file in the shared space
sudo -u nobody rm -f /tmp/mine.txt # another user tries to delete it
ls -l /tmp/mine.txt # still there?
rm /tmp/mine.txt # you, its owner, may✅ Expected result — an error, on purpose — click to reveal
drwxrwxrwt 10 root root 4096 Sep 2 15:42 /tmp
rm: cannot remove '/tmp/mine.txt': Operation not permitted
-rw-rw-r-- 1 zaeem zaeem 0 Sep 2 15:57 /tmp/mine.txtthen silence for your own rm — gone.
What to read out of it:
- nobody had directory-write (the third rwx) — by B2's rule alone the delete should have worked. The trailing t overrode it: not the owner, not root, denied. Note the error family: Operation not permitted — a kernel rule, not a permission bit.
- The full mode 1777 reads: sticky bit (1), then everyone-everything (777). Safe because of the 1, not despite the 777.
Part D — Interview questions
🎯 "What are SUID, SGID and Sticky Bit?" — asked verbatim in GeeksforGeeks' Linux Interview Questions (70+ questions, updated July 2026)
Three extra mode bits beyond rwx. SUID (4---): an executable runs with its owner's identity — /usr/bin/passwd runs as root so users can update /etc/shadow through controlled code; ignored on scripts. SGID (2---): on executables, run with the owner group; on directories, new entries inherit the directory's group — the shared-team-folder pattern. Sticky (1---): on directories, only an entry's owner (or the directory's owner, or root) may delete or rename it despite world-write — /tmp is the canonical 1777. Displayed as s in the owner/group x-slot and t in the others x-slot; capitals mean the underlying x is absent.
The details that separate candidates: one concrete example per bit (passwd, team dir, /tmp) rather than definitions; the s/S capitalization tell; the security angle — setuid binaries as audit targets (find / -perm -4000 — Module 6 gives you the command); and sticky's name being a historical leftover.
🎯 "Change the permissions of a file named 'file.txt' to give read, write, and execute permissions to the owner, and only read permission to others" — a live task, verbatim from Turing's 100+ Linux interview questions (2025)
chmod 744 file.txt — owner rwx (4+2+1=7), group r (4), others r (4) — or symbolically chmod u=rwx,go=r file.txt. Verify: ls -l file.txt → -rwxr--r--. (Pedantry that earns points: the task as worded specifies owner and others but not group; 744 grants group read too, matching the almost-certain intent — say you noticed.)
The details that separate candidates: offering both dialects and stating when each is right — octal for absolute states, symbolic for surgical edits; verifying with ls -l unprompted; and the habit of reading tasks precisely — interviewers plant ambiguities on purpose.
Part E — Toolkit
E1. Production practice — symptoms and fixes
| Symptom | What is really happening | What to run | The fix |
|---|---|---|---|
| Permission denied reading a file that exists | The triplet that applies to this identity lacks r | ls -l thefile · id (or id serviceuser) | Grant the one missing right — usually group membership or a group-bit chmod, never 777 |
| Service can't read config although "the file is 644" | A directory on the path lacks x for the service's identity — every component must be traversable | sudo -u serviceuser cat /full/path · ls -ld each path component | Add x for the right audience on the blocking directory |
| Operation not permitted from chown / rm in /tmp | A kernel rule, not a permission bit: chown is root-only; sticky directories protect others' entries | ls -ld the directory — look for t · check who owns the entry | Use sudo if legitimately yours to administer; otherwise it is working as designed |
| Added user to a group; access still denied | Group list is snapshotted at login — the running session predates the change | id in the user's own session vs id username | Log out and back in (or new login session); confirm with id |
| ./script.sh: Permission denied | No execute bit — files are never born executable | ls -l script.sh | chmod +x script.sh — or run bash script.sh, which needs only read |
| SSH refuses keys after a "fix" opened permissions | Security-conscious software rejects too-open files (600/700 expected) | ls -l ~/.ssh/ | chmod 700 ~/.ssh; chmod 600 ~/.ssh/* — details in Module 15 |
E2. Capstone — four tickets
🎫 Ticket 1 — "App uploads directory: web service can't write"
Ticket text: "The web app (runs as user www-data) throws Permission denied saving uploads to /srv/app/uploads. Deploys are done by user deploy, who owns everything under /srv/app. Fix it properly — last time someone 'fixed' this kind of thing with 777 and security flagged it."
Worked answer: diagnose as the service — sudo -u www-data touch /srv/app/uploads/probe reproduces the refusal; ls -ld /srv/app/uploads shows why (e.g. drwxr-xr-x deploy deploy — www-data falls to "others": r-x, no w). The proper grant: give the directory to the service's group and open the group triplet — sudo chgrp www-data /srv/app/uploads && sudo chmod 775 /srv/app/uploads (or 770 if others shouldn't even read). Consider chmod g+s on it (setgid) so future upload files inherit the group automatically. Re-probe as www-data; remove the probe file. Why not 777: world-write means any local account can plant or delete uploads — the audit finding writes itself.
🎫 Ticket 2 — "Postmortem: chmod -R 777 'fix' broke SSH for the deploy user"
Ticket text: "During an incident, an engineer ran chmod -R 777 /home/deploy to 'rule out permissions'. The incident's actual cause was elsewhere; now deploy cannot SSH in at all. Explain the mechanism and write the remediation steps."
Worked answer: mechanism — SSH checks permissions and refuses to honour credentials that are too open: a world-readable private key or writable ~/.ssh fails validation, so the very tool used for access rejects the "fix". (777 also made every file in the home writable by all users — an incident of its own.) Remediation: chmod 700 /home/deploy/.ssh, chmod 600 /home/deploy/.ssh/authorized_keys (and any keys), chmod 755 /home/deploy — then audit what else in the tree held secrets while world-readable, and rotate any exposed keys. Postmortem lesson: permissions are never "ruled out" by abolishing them — they are diagnosed with ls -l + id + sudo -u, three commands that would have cost forty-five seconds.
🎫 Ticket 3 — "New hire added to sudo group, swears sudo still refuses"
Ticket text: "IT ran usermod -aG sudo priya this morning. Priya still gets 'priya is not in the sudoers file. This incident will be reported.' Her terminal has been open since yesterday. Explain and resolve."
Worked answer: the smoking gun is "open since yesterday" — group membership is read at login, and her session predates the grant. Proof: in her terminal id (old list, no sudo group) versus id priya (fresh lookup: sudo present). Resolution: log out and back in — or start a fresh login session (su - priya works in a pinch) — then id shows 27(sudo) and sudo behaves. Also worth confirming IT used -aG and not -G: without -a, usermod replaces the supplementary list, silently removing her other groups — check id priya against what she is supposed to hold.
🎫 Ticket 4 — "Why can interns delete each other's files in the shared folder?"
Ticket text: "We made /srv/shared mode 777 so the intern team could collaborate. Today one intern's rm -r deleted another's week of work. Make sharing safe, and explain what /tmp does differently — it's 777 too and this never happens there."
Worked answer: B2's rule — directory-write means "may delete any entry", so 777 handed every user deletion rights over everyone's files. /tmp survives its 777 because of the eleventh bit: ls -ld /tmp → drwxrwxrwt, mode 1777 — the sticky bit restricts deletion to each entry's owner. Fix in one line: sudo chmod +t /srv/shared (now 1777). Better still, scope it: sudo chgrp interns /srv/shared && sudo chmod 2770 /srv/shared — setgid so new files inherit the interns group, no access for outsiders at all, and add +t if intra-team deletion protection is also wanted. And the week of work: restored from backups, or it is gone — Module 3's shredder rule has no exceptions for interns.
E3. Documentation reference
| Topic | Authoritative source | Verified link |
|---|---|---|
| Identity | id(1), passwd(5), group(5), shadow(5) | id(1) · passwd(5) · group(5) · shadow(5) |
| Permissions | chmod(1), path_resolution(7) | chmod(1) · path_resolution(7) |
| Ownership | chown(1), chgrp(1) | chown(1) · chgrp(1) |
| Elevation | sudo(8), sudoers(5), su(1) | sudo(8) · sudoers(5) · su(1) |
| Account management | useradd(8) | useradd(8) |
| Where the bits live | inode(7) | inode(7) |
E4. Self-assessment
Answer out loud, without notes. The section number tells you where to re-read.
- What is special about UID 0 — precisely? Not "has all permissions"; state the mechanism. (A1)
- Primary versus supplementary groups: which lands on files you create, and when does a membership change take effect? (A2)
- Why is /etc/passwd world-readable, and what is the x in its second field? (A3–A4)
- Recite the kernel's permission-check order, and explain how an owner can be denied what "others" are allowed. (B1)
- Translate on sight: 640, 755, 1777, -rwsr-xr-x, drwxrwxrwt. (B4, D2, D3)
- What do r, w, x each mean on a directory, and which permission governs deleting a file? (B2)
- Symbolic vs numeric chmod: which is relative, which absolute, and when is each the right tool? (B3–B4)
- Umask 027: what are new files and directories born as, and why can no umask produce an executable file? (B5)
- Why can't you chown your own file to someone else, and who can? (C1)
- Make the case for sudo over root login in four points, then explain what sudo -u www-data cat file is for. (C2–C3)
- How does passwd write to a file its caller cannot read? Include why the same trick is ignored for scripts. (D2)
- /tmp is world-writable and yet safe — reconcile that with your answer to question 6. (D3)
E5. Sources
GeeksforGeeks — Linux Interview Questions (70+) (updated July 2026) · Turing — 100+ Linux Interview Questions (2025) · InterviewBit — Linux Interview Questions (2025).
Corpus honesty note: permissions are the best-covered Linux interview topic in print — the questions above are all genuinely asked, recently. Two gaps in the published corpus worth knowing: sudo/sudoers design questions barely appear in written sets (they are asked live, usually as "how do you manage access?"), and directory-permission semantics (deletion!) appear in almost no question bank despite being a favourite live probe. Both are covered here at the depth interviews actually reach.
All documentation links on this page were fetched and confirmed reachable on 2 September 2026.