File Permissions (chmod, chown)

The first character is the type: hyphen for a regular file, d for a directory, l for a symlink, c/b for device nodes, s for a socket, p for a named pipe. For daily work you live in - and d. The next nine characters are three triplets: owner (user), group, and others (everyone else on the machine). r is read, w is write, x is execute. A dash in a slot means that permission is off for that class of identity.

On a regular file, r lets you cat, copy, or hash the contents; w lets you change, truncate, or overwrite; x lets the kernel treat the file as an executable (scripts still need a shebang or an interpreter). On a directory the meanings shift and people get hurt by ignoring that: r lets you list names (ls), x lets you enter the directory (cd) and resolve paths inside it, and w lets you create, rename, or delete directory entries. A directory without x is a locked room: you may know it exists, but you cannot walk in even if you somehow know a filename inside.

The sticky bit on directories (t in the others-execute slot, as on /tmp) adds another rule: only the file owner (or root) may delete or rename a name inside, even if the directory is world-writable. That is why shared scratch spaces can be writable without becoming a free-for-all delete arena. Special bits (setuid, setgid, sticky) show up as s/S/t in ls -l; you do not need every edge case today, but you must not confuse "directory execute" with "run this folder like a .exe."

Each triplet is also a number: read=4, write=2, execute=1. Add them. 7 is rwx, 6 is rw-, 5 is r-x, 4 is r--, 0 is ---. Three digits set owner, group, others. chmod 644 file means rw-r--r-- (owner writes; everyone may read). chmod 755 script means rwxr-xr-x (owner may run; others may read and run but not edit). chmod 600 secret means rw------- (only the owner). Those three modes cover almost every beginner security decision. chmod 700 on a private directory is the folder twin of 600: only you traverse and list.

chmod also accepts symbols: u (user/owner), g (group), o (others), a (all), then + or - or = and r/w/x. chmod u+x script.sh adds execute for the owner only. chmod go-w secret.txt strips write from group and others. chmod a=r notes.txt sets everyone to read-only (dangerous if you meant owner-write). Prefer explicit octal when you care about the final absolute mode; prefer symbolic when you want a surgical +x without guessing the other bits. After either form, re-read with ls -l — never trust muscle memory alone.

chown changes the owner username and optionally the group: sudo chown ana:developers project/. Ownership is who the first triplet applies to. You usually need root to give a file to another user. Wrong chown on system files breaks packages and services; do not practice chown on /etc or another person's home. On your own VM you may explore carefully; on a shared school host, stay with chmod on files you create.

umask is the quiet partner. New files are not born as 666 or 777; the kernel subtracts the umask from the creation mask. A umask of 022 yields 644 files and 755 directories — group and others cannot write. A umask of 000 yields world-writable defaults. Run umask (and umask -S) on a shared box; a surprising 000 is a finding, not a preference. Scripts that install with mode 666 then "fix later" often never fix later.

Incident responders hunt world-writable paths (-perm -0002 in find language you will meet later), unexpected setuid binaries, and secrets that are group- or world-readable. Developers leave 777 "just for now" after a Permission denied error; months later that directory still accepts writes from every local account. Your job as a learner is to make 644/755/600 intentional and to treat 777 as a temporary demo you undo.

Private keys, API tokens, and .env files belong at 600 (or stricter directory 700). Public HTML and READMEs often sit at 644. Shared team drop folders use a dedicated group plus 640/660, not 777. If a service cannot write, grant that service user — not the entire universe. That single habit prevents more local privilege abuse than memorizing exotic ACL syntax.

Create a lab folder in your home directory. Never chmod the real root filesystem, /etc, or anyone else's files. Watch ls -l after each chmod so the nine bits become a language you can read under pressure. Optionally flip notes.txt to 777 briefly so your eyes learn the carnival of rwxrwxrwx — then put 644 back. That restore step is the security lesson, not a footnote.

mkdir -p "$HOME/cyberlium-lab/m03-perms"
cd "$HOME/cyberlium-lab/m03-perms" || exit 1

echo 'practice notes' > notes.txt
echo 'demo-secret-not-real' > secret.env
printf '%s
' '#!/bin/sh' 'echo hello from lab' > hello.sh

umask
umask -S
ls -l

chmod 644 notes.txt      # rw-r--r--
chmod 600 secret.env     # rw-------
chmod 755 hello.sh       # rwxr-xr-x
ls -l

chmod go-w notes.txt     # strip group/other write if present
ls -l notes.txt

chmod 777 notes.txt
ls -l notes.txt          # -rwxrwxrwx  ← attacker gold on a real secret
chmod 644 notes.txt

mkdir -p private-dir
chmod 700 private-dir
ls -ld private-dir

chmod 777 /
chmod -R 777 /etc  /var  /home
chmod 777 ~/.ssh/id_rsa
chown root files that are not yours on a shared host
chown usually needs sudo; skip it unless this is YOUR VM.

You can read rwx, pick 644/755/600 on purpose, respect umask, and treat 777 as a finding you undo. You know when chown is appropriate (usually not on someone else's tree) and that sticky directories solve a different problem than world-writable "fixes." Next — sudo & Root Access — when you actually need UID 0, and how not to live there all day.