ced4568andClaude Sonnet 5
15b616274b
Adds all 6 ROOT 01 modules (how computers run software, the shell, filesystem navigation, files & text, processes, users & permissions foundations), each with a real lesson, demonstration/guided exercise, knowledge check where warranted, a hands-on Lab, and a reflection — 35 activities, 29 new content files. Adds 6 new hands-on Linux scenarios (linux-inspect-hardware, linux-shell-basics, linux-filesystem-navigation, linux-files-and-text, linux-process-management, linux-permissions-foundations) plus 2 MCQ scenarios, using the existing generic scenario/ validation engine (docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md §1) — every one tested end-to-end via the real scenario setup/validate API, including negative tests confirming they correctly FAIL when not actually solved (e.g. the process-management scenario fails while the target process is still running; the permissions scenario is tested against a real `su - labuser` denial). Wires rootnode-linux-foundations-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. Adds a real, server-side ROOT 01->02->03->04->05 course prerequisite chain (courses.prerequisites) — verified live on two students: one who completed ROOT 01 sees ROOT 02 unlock; a fresh student sees ROOT 02 correctly locked while 03/04/05 stay vacuously satisfied (their own prerequisite courses are still empty). ROOT 06+ and the Capstone are unaffected. Co-Authored-By: Claude Sonnet 5 <[email protected]>
3.1 KiB
Users and Permissions Foundations
Users, groups, and ownership
Every file on Linux has an owner (a user) and a group. ls -la shows both: the third
column is the owning user, the fourth is the owning group. Multiple users can belong to the same
group, which is how permissions get shared across a team without giving every individual user
direct ownership.
Read, write, execute — for three different audiences
Every file has permissions for THREE separate audiences: the owner, the group, and everyone else ("other"). Each audience gets some combination of:
- read — can view the file's contents (or list a directory's contents)
- write — can modify the file (or create/delete files inside a directory)
- execute — can run the file as a program (or enter/traverse into a directory)
ls -la shows this as a 10-character string like -rw-r--r--: the first character is the file
type, then three groups of rwx for owner/group/other.
Reading and setting permissions as octal numbers
Each rwx triplet can be written as one digit: read=4, write=2, execute=1, summed together.
rw- = 4+2 = 6. r-- = 4. So 644 means: owner can read+write (6), group can read-only
(4), everyone else can read-only (4) — a very common, sensible default for a regular file.
chmod 644 <file> sets exactly that.
sudo: temporary elevated privilege
Rather than logging in AS the root user (with permanent full access to everything), sudo <command> runs just that one command with elevated privileges, after checking you're allowed
to. This is deliberate: the less time you spend with full privileges, the smaller the window for
a mistake (or a compromised session) to do serious damage — the exact same reasoning behind
"least privilege," which this module introduces by name for the first time.
Least privilege: the principle, not just the command
Least privilege means: grant exactly the access something needs to do its job, and nothing more. A user who only needs to read a file shouldn't also be able to write it. A process that only needs to read one directory shouldn't have write access to the whole filesystem. This principle isn't specific to Linux permissions — you'll meet it again, in a much more elaborate form, in ROOT 09's Kubernetes RBAC and SecurityContext content. This module is where it starts.
Instructor Notes
Lesson goal: Build real fluency with rwx/octal permissions AND plant the least-privilege PRINCIPLE explicitly — not just command syntax, since ROOT 09 depends on students already having this vocabulary.
Approximate timing: 15 minutes read; 10 minutes live.
Common misconception to watch for: students often memorize "644 = read/write" without being able to derive it from 4+2+1 — walk through the arithmetic explicitly rather than treating the numbers as magic.
Discussion question: "Why not just make everything readable and writable by everyone, to avoid permission headaches?" (Good setup for the least-privilege principle — let students generate the security argument themselves before you confirm it.)