ch04/l01

Mode bits and symbolic changes

Translate `rwx` and octal modes into real access decisions.

chmod u+x 25 min read, 30 min lab foundation

Linux file modes express permissions for user, group, and other. Symbolic changes such as `u+x` are often safer than replacing the entire mode because they describe intent narrowly.

In the field

A script will not run. You need to add execute only for the owner, not open it to everyone.

Worked command

$ ls -l deploy.sh-rw-r----- 1 app app 120 deploy.sh$ chmod u+x deploy.sh$ ls -l deploy.sh-rwxr----- 1 app app 120 deploy.sh
Anti-pattern

Do not use `chmod 777` as a debugging shortcut.

Safer pattern

Inspect current mode, change the narrowest bit, inspect again.

Knowledge check

deploy.sh is -rw-r----- owned by app:app and the owner cannot run it. You run `chmod u+x deploy.sh`. What changes?

  • A Execute is added for the owner only; group and other are untouched
  • B Execute is added for everyone, since u+x sets the whole user/group/other triad
  • C The file becomes -rwxrwxrwx, the safe default for scripts
  • D Read is removed from group because symbolic mode replaces the existing bits
Show the answer

Correct: A. Execute is added for the owner only; group and other are untouched

Why

Symbolic `u+x` adds the execute bit to the user (owner) class and leaves group and other exactly as they were. The tempting distractor confuses `u` (owner) with `a` (all); only `a+x` or a full octal would touch every class.

Practice checklist

  1. Create a script in a disposable directory.
  2. Check its mode.
  3. Add owner execute with symbolic chmod.
  4. Verify the result.

Deliverable evidence

  • Before and after `ls -l` output.
  • A sentence explaining the changed bit.
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.

rwxu/g/ochmod u+xchmod 640
Recall practice · Scenario -> next check

cue A script will not run; add execute for the owner only, without touching group or other.

show recall target

chmod u+x deploy.sh