Day 7: Filesystem, permissions, users & groups
The filesystem hierarchy
Linux organizes everything — files, devices, even running processes — under a single tree rooted at /. A few directories you'll live in constantly: /etc (system configuration), /var (variable data — logs, caches), /home (user directories), /usr (installed programs and libraries), /proc (a virtual filesystem exposing live kernel/process state — cat /proc/cpuinfo is reading live kernel data, not a file on disk).
Permissions
Every file has an owner (user), a group, and three permission triads — read/write/execute — for the owner, the group, and everyone else. ls -l shows this as a string like -rwxr-xr--. Numerically, read=4, write=2, execute=1, summed per triad — so 754 means owner=rwx (7), group=r-x (5), other=r-- (4).
ls -l /etc/passwd
# -rw-r--r-- 1 root root 2894 ... /etc/passwd
chmod 640 secrets.env # owner rw, group r, other nothing
chmod u+x deploy.sh # add execute for owner only
chown appuser:appgroup app.logThe mistake that shows up in every security review
World-writable or world-readable files that hold secrets (chmod 777, or forgetting other permissions on a .env file) are one of the most common findings in real audits — and directly relevant to Phase 26 (OWASP) and Phase 11 (Kubernetes Secrets).
Users and groups
Every process runs as some user; root (UID 0) bypasses permission checks entirely, which is exactly why running containers as root (Phase 11's Pod Security Standards) is a real security concern, not a formality. Groups let you grant the same permissions to multiple users without repeating owner assignments.
Key terms
- inode permissions
- Read/write/execute bits stored per file for owner, group, and other.
- root
- UID 0 — the superuser account that bypasses normal permission checks.
- /proc
- A virtual filesystem exposing live kernel and process state as if it were files.
What does `chmod 640 file` grant?
