Terminal.Drill Get the app
ch04/l02

Ownership, groups, and umask

Separate who owns a file from what permissions allow.

chown user:group 20 min read, 25 min lab foundation

Ownership answers who the user and group owners are. Mode bits answer what each class can do. `umask` sets default permissions for newly created files and directories by subtracting permissions.

In the field

A service account owns config, but a deployment group needs read access.

Worked command

$ stat app.conf$ umask0022$ chown app:deploy app.conf$ chmod 640 app.conf
Anti-pattern

Do not recursively chown a tree until you know exactly which paths and service users are involved.

Safer pattern

State the owner, group, intended readers, and intended writers before changing access.

Knowledge check

app.conf is mode 640 and a deploy engineer still gets 'Permission denied' reading it. What is the most likely cause?

  • A The engineer is not the owner and not in the file's group, so they fall to 'other' (---)
  • B 640 forbids reading for everyone, including the owner
  • C The file needs 777 so every account can read it
  • D umask 0022 stripped the read bit after the file was created
Show the answer

Correct: A. The engineer is not the owner and not in the file's group, so they fall to 'other' (---)

Why

Mode is correct but it is evaluated against the file's owner and group; a user outside both lands in the 'other' class, which 640 gives no access. Jumping to 777 'fixes' it by removing the boundary entirely instead of adding the engineer to the group.

Practice checklist

  1. Create test files.
  2. Compare owner/group/mode with `stat`.
  3. Write a planned owner/group/mode change before applying it.

Deliverable evidence

  • A permission repair plan.
  • Before/after owner, group, and mode.
Teaching diagramch04 · mental model
-rwxr----- 1 app deploy deploy.sh user rwx group r-- other --- mode = WHAT each class may do ownership owner app : group deploy WHO the classes resolve to umask 0022 subtracts default bits new files: 644 / 755 sudo scoped, after read-only change the narrowest bit, inspect before and after

shows: How a file's access splits into ownership (who) and mode bits (what) per user/group/other class, how umask seeds defaults, and where sudo crosses the boundary.

does not prove: It shows the model, not your case: only running ls -l, stat, id, and sudo -l on the actual file proves who you are and what access you currently hold.

Memorize this

Commit these to memory, then drill them until recall is automatic.

chowngroupumask640750

Reference

chown user:groupstat
Recall practice · Meaning -> command

cue Owner keeps the file, but a deploy group needs read-only access; set group ownership and a group-readable mode.

show recall target

chown app:deploy app.conf && chmod 640 app.conf

See this drill type Practice recall in the app