Linux file permissions (chmod), explained without the jargon

Start with what ls -l is actually telling you

Run ls -l in any Linux directory and the first column of every line looks like -rwxr-xr--. That string is ten characters, and once you know how to split it, it stops being noise. The first character says what kind of thing this is — - for a regular file, d for a directory. The other nine split into three groups of three: what the owner can do, what the group can do, and what everyone else can do. Each group of three is always the same order: read, write, execute — r, w, x — with a dash standing in for "not allowed."

So rwxr-xr-- means: the owner can read, write, and execute; the group can read and execute but not write; everyone else can only read. Once you can read that string at a glance, half the mystery around chmod is already gone, because chmod is just a way of setting those same nine slots.

What read, write, and execute actually mean

These three letters mean something slightly different depending on whether you're looking at a file or a directory, and this is where a lot of the confusion actually comes from.

For a file: read lets you view its contents, write lets you modify or delete its contents, and execute lets you run it as a program or script.

For a directory, it's less intuitive: read lets you list what's inside it (ls the directory), write lets you create or delete files inside it, and execute lets you actually enter it or access files inside it by name — even ones you already know the exact path to. This is why you'll sometimes see a directory with no read permission but execute permission still granted: someone can cd into it and access a specific file if they know it exists, but they can't list what else is in there. It's a deliberate, narrow kind of privacy.

Where chmod's numbers come from

The three permissions per group aren't arbitrary — they're powers of two, which is why they add up the way they do: read is 4, write is 2, execute is 1. Add up whichever ones apply and you get a single digit from 0 to 7 for that group. Full permissions (read + write + execute) is 4+2+1 = 7. Read and execute only is 4+1 = 5. Read only is 4. No permissions at all is 0.

A chmod command always gives you three of these digits in a row — owner, group, others — so chmod 754 file.sh means: owner gets 7 (rwx, everything), group gets 5 (r-x, read and run but not edit), everyone else gets 4 (r--, read only). That's the exact same permission set as rwxr-xr-- in the ls -l output. Once you see that a three-digit chmod number is just three of these read/write/execute totals stacked next to each other, you can go from "I need to memorize a chart" to "I can work it out in five seconds," and that's really the whole trick.

Symbolic mode, for when you don't want to do the math

Numbers are fast once you know them, but Linux also lets you change permissions symbolically, which is often clearer for a small edit. chmod u+x script.sh adds execute permission for the user (owner) without touching anything else — the single most common permissions fix you'll ever run, usually right after downloading or writing a script and getting a Permission denied error trying to run it. chmod go-w file.txt removes write access from group and others, leaving the owner's permissions untouched. The letters are u (user/owner), g (group), o (others), and a (all three); the operators are + to add, - to remove, and = to set exactly.

Why this actually matters, beyond passing a quiz

Permissions are the mechanism that makes a multi-user operating system safe to use at all. Without them, any process running as any user could read your SSH private key, overwrite another user's files, or modify a system binary that every program on the machine relies on. When you see a warning that your SSH key file has permissions that are "too open" and SSH refuses to use it, that's not SSH being picky — a private key readable by other users on the machine defeats the entire point of it being private, so SSH enforces 600 (owner read/write only, nobody else anything) as a hard requirement rather than a suggestion.

It also explains one of the most common early-career support tickets: a web server returning "403 Forbidden" for a file that clearly exists. Nine times out of ten, that's not a bug in the application — it's a directory somewhere in the path missing execute permission for the user the web server runs as, meaning the server can't even traverse into the folder to reach the file, regardless of what permissions the file itself has. Once you understand that directories need execute permission just to be entered, that error stops being mysterious and becomes a five-second ls -ld away from solved.