feat(root01): author Computing & Linux Foundations, and the real 01->05 prerequisite chain

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]>
2026-08-26 12:59:52 -05:00
parent 87526bcf7f
commit 15b616274b
37 changed files with 1549 additions and 0 deletions
@@ -0,0 +1,59 @@
+# 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:
+
+- **r**ead — can view the file's contents (or list a directory's contents)
+- **w**rite — can modify the file (or create/delete files inside a directory)
+- e**x**ecute — 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.)
@@ -0,0 +1,55 @@
+# Demonstration: A Real Permission Denial, and the Real Fix
+
+## OBSERVE
+
+A file is owned by root with permissions `600` (owner read/write only):
+
+```
+$ stat -c '%a %U' data.txt
+600 root
+```
+
+## HYPOTHESIS
+
+Predict: can a different, non-root user read this file?
+
+## INSPECT
+
+```
+$ su - labuser -c "cat data.txt"
+cat: data.txt: Permission denied
+```
+
+Confirmed — `600` grants nothing to group or other, so `labuser` (neither the owner nor root)
+is correctly denied.
+
+## CHANGE
+
+Grant read access to everyone, while keeping write access limited to the owner:
+
+```
+$ chmod 644 data.txt
+$ stat -c '%a' data.txt
+644
+```
+
+## VERIFY
+
+```
+$ su - labuser -c "cat data.txt"
+sensitive
+```
+
+The exact same command that failed before now succeeds — the permission bits, not the file's
+actual content, were the only thing that changed.
+
+## Instructor Notes
+
+**Demo goal:** Show a permission denial as a real, reproducible fact (not just a described
+error message) and the exact minimal fix, not an overcorrection like `chmod 777`.
+
+**Approximate timing:** 8 minutes live.
+
+**Common mistake to watch for:** students reaching for `chmod 777` "to make the error go away"
+— explicitly name why that's wrong (it also grants WRITE to everyone, not just the read access
+actually needed) and connect it back to least privilege.
@@ -0,0 +1,38 @@
+# Knowledge Check: Users and Permissions Foundations
+
+---
+
+**1. A colleague says "permission denied" and fixes it with `chmod 777`. What's wrong with
+that fix?**
+
+*Answer:* `777` grants read, write, AND execute to the owner, group, AND everyone else — almost
+always far more access than the actual problem required. It "fixes" the symptom while violating
+least privilege, usually granting write access nobody asked for.
+
+---
+
+**2. What does the permission `644` actually mean, broken down?**
+
+*Answer:* Owner: read+write (4+2=6). Group: read-only (4). Other: read-only (4). Nobody but the
+owner can modify the file; everyone can read it.
+
+---
+
+**3. Why does `sudo <command>` exist instead of just logging in as root permanently?**
+
+*Answer:* It grants elevated privilege only for the one command that needs it, minimizing the
+time spent with full access — reducing the chance a mistake (or a compromised session) causes
+serious, wide damage.
+
+---
+
+**4. State the least-privilege principle in your own words.**
+
+*Answer:* Grant exactly the access something needs to do its job, and nothing more.
+
+## Instructor Notes
+
+**Facilitation:** Question 1 is worth discussing as a group — most students have seen `chmod
+777` somewhere online as "the fix," and unlearning that habit early matters.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,32 @@
+# Guided Exercise: Pick the Minimal Permission, Not the Easy One
+
+This is a paper exercise — commit to an answer before checking it in the Lab.
+
+## Your task
+
+For each situation, write the exact `chmod` octal value that grants the MINIMUM permission
+actually needed:
+
+1. A private SSH key file — only the owner should ever read or write it, nobody else, no
+   execute for anyone.
+2. A shared script every user on the system should be able to run, but only the owner should be
+   able to edit.
+3. A log file every user should be able to read (for troubleshooting), but only a logging
+   service (the owner) should write to it.
+
+## A worked shape to check yourself against
+
+1. `600` — owner read+write (6), nothing for group or other (0, 0). This is the real, standard
+   permission for private SSH keys — SSH itself refuses to use a key file that's more open than
+   this.
+2. `755` — owner read+write+execute (7), group and other read+execute (5, 5) so they can run it
+   but not modify it.
+3. `644` — owner read+write (6), group and other read-only (4, 4).
+
+## Instructor Notes
+
+**Facilitation:** Item 1 is a good moment to mention that this isn't a hypothetical rule — SSH
+genuinely refuses to use an overly-permissive private key file, a real-world consequence of
+exactly this principle.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
@@ -0,0 +1,33 @@
+# Reflection: Least Privilege Is a Habit, Not a One-Time Fix
+
+## Reflection questions
+
+1. Before this module, what would you have done the first time you hit a "permission denied"
+   error? How does that compare to what you'd do now?
+2. Name one place outside of file permissions where you'd expect "grant only what's needed" to
+   matter (a user account, an API key, a service's network access — anything).
+
+## Real Ops takeaway
+
+**Least privilege is the single idea from this entire module that reappears the most across
+the rest of ROOT_.** File permissions are just the first, most concrete place you'll apply it —
+ROOT 09 applies the exact same principle to Kubernetes RBAC (what can a user or workload
+actually DO) and SecurityContext (what can a container actually access). Getting comfortable
+asking "what's the minimum this actually needs" now, on a file you can see and touch, makes that
+same question much easier to ask later about something more abstract, like a ServiceAccount's
+permissions.
+
+This module is complete. This is the end of ROOT 01 — continue to ROOT 02: Linux
+Administration & Networking.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 2 works well as a round-robin — the
+variety of answers (API keys, database credentials, network firewall rules) is itself useful
+evidence of how far this one principle travels.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.
+
+**Milestone note:** this is the last module of ROOT 01 — consider a short recap of the whole
+course's arc (hardware → shell → filesystem → files/text → processes → permissions) before
+moving on, so students see it as one coherent foundation rather than six separate topics.