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]>
60 lines
3.1 KiB
Markdown
60 lines
3.1 KiB
Markdown
# 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.)
|