Permissions Deep Dive

In one line

Every file has three permission sets — owner, group, and everyone else — each independently controlling read, write, and execute, and chmod is how you change any of them.

0/7 · 0%

Think of it like this

A locker with three separate keys — one for you (the owner), one shared among your team (the group), and the locker's general public-facing slot (everyone else). Each 'key' independently controls what that category of person can do — read the contents, put new things in (write), or use it as a tool (execute).

Key ideas

01
ls -l's permission column reads as ten characters: the first is the file TYPE (- for a regular file, d for a directory), then three groups of three: owner (rwx), group (rwx), other (rwx) — r (read), w (write), x (execute), or - for 'not granted.' -rwxr-xr-- means the owner can read/write/execute, the group can read/execute, and everyone else can only read.
02
For a REGULAR FILE: read (r) means you can view its contents, write (w) means you can modify it, execute (x) means you can RUN it as a program/script — a text file without the execute bit set literally cannot be run directly, even if its contents are a perfectly valid script.
03
For a DIRECTORY specifically, the meanings shift: read (r) lets you LIST its contents (ls it), write (w) lets you CREATE or DELETE files inside it, and execute (x) — genuinely non-obvious at first — lets you actually ENTER it (cd into it) or access files inside by exact name/path. A directory with r but not x lets you see filenames but not open any of them.
04
chmod changes permissions two ways: SYMBOLIC (chmod u+x file adds execute for the owner; chmod g-w file removes write for the group; u/g/o/a for user/group/other/all) or NUMERIC/octal (chmod 755 file — each digit is r=4, w=2, x=1 added together per category: 7=rwx, 5=r-x, 5=r-x, so 755 means owner gets everything, group and other get read+execute only).
05
umask sets the DEFAULT permissions new files get created with (typically 022, which subtracts write access for group/other from the OS's own default of 666 for files / 777 for directories) — most people never need to change it, but it explains why a freshly created file is 644 (rw-r--r--) rather than fully open by default.

In your stack

→
A Spring Boot app's application.properties (often containing a database password) should typically be 600 (owner read/write only, nothing for group or other) — the same 'least privilege' instinct as running the app as a dedicated non-root user, applied to the config file itself.

Code & diagrams

PermissionBitsdiagram

-rwxr-xr-- decoded — three independent categories, each with its own read/write/execute.

Rendering diagram…

permissions.shmarkdown

Practice on a throwaway file — nothing here affects anything beyond it.

# Create a test file and inspect its default permissions
touch secret.txt
ls -l secret.txt
# -rw-r--r-- 1 you you 0 ... secret.txt  (644 by default, per your umask)

# Restrict it to yourself only — the "secrets file" pattern
chmod 600 secret.txt
ls -l secret.txt
# -rw------- 1 you you 0 ... secret.txt

# Make a script executable (needed to run it directly)
echo '#!/bin/bash' > myscript.sh
echo 'echo "hello from a script"' >> myscript.sh
./myscript.sh              # fails: Permission denied
chmod +x myscript.sh
./myscript.sh               # now works

# Symbolic vs numeric — these two commands do the same thing
chmod u+rwx,g+rx,o+rx myscript.sh
chmod 755 myscript.sh

Explain it without notes

A directory has read permission but NOT execute permission for a given user. What exactly can and can't that user do with it?

Why does a freshly downloaded shell script usually fail with 'Permission denied' the first time you try to run it, even though you can clearly open and read its contents?

Practice

Create a directory, remove its execute permission for yourself with chmod u-x, then try to cd into it and ls it — observe which one still works and which one fails, then restore the permission.

Write a two-line shell script, confirm it fails to run directly before chmod +x, make it executable, run it successfully, then explain in one sentence what changed.

Trade-offs

↔
Overly restrictive permissions (locking yourself out of your own files) is annoying but safe; overly permissive permissions (world-writable config files, chmod 777 used as a lazy fix for a permission error) is a genuine, common security weakness — when in doubt, the safer direction to err is toward MORE restrictive, then loosen only as needed.

Done when you can

I can read a permission string like -rwxr-xr-- and explain every character.
I understand read/write/execute mean something different for directories than for regular files.
I can use chmod in both symbolic and numeric form.

Command Palette