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]>
33 lines
1.3 KiB
Markdown
33 lines
1.3 KiB
Markdown
# 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.
|