When I first learned Linux permissions, I treated them as syntax to memorize.
chmod 755. chown root:root. -rwxr-xr-x.
I could read the notation and run the commands. What I didn’t have was the model behind it — why the system works the way it does, and what it’s actually protecting.
That model matters. Because once you see permissions as trust boundaries instead of access flags, you start making better decisions about every system you touch.
The problem with memorizing flags
Most Linux tutorials teach permissions as a number or a string.
rwxr-xr-x means the owner can read, write, and execute. The group can read and execute. Everyone else can read and execute.
That’s correct. But it’s describing the output, not the principle.
The underlying question is: who do you trust, and with what?
Every file and process in Linux has an owner. Every action on that file runs as some identity. Permissions are the system’s way of saying: given who you are, what are you allowed to do here?
How it actually works
Linux permissions map to three categories and three operations.
Categories:
- Owner — the user who created the file
- Group — a named set of users with shared access
- Other — everyone else on the system
Operations:
- Read (
r) — can see the content - Write (
w) — can modify the content - Execute (
x) — can run it (for files) or enter it (for directories)
Each category gets its own read/write/execute combination. That’s the nine bits behind the permission string.
But here’s what that’s really describing: a layered trust model.
owner → highest trust, most access
group → controlled trust, shared access
other → lowest trust, minimal access
When you write chmod 755, you’re saying: the owner fully trusts this file (7 = rwx), the group can read and execute it (5 = r-x), and everyone else can too (5 = r-x). You’re encoding a trust decision.
Why this framing matters
Consider a production web server.
Your application runs as a service user — say, www-data. Your configuration files contain secrets: database credentials, API keys, environment variables.
If those files are owned by root but readable by other, any process on the system can read your secrets. The permissions syntax is valid. The trust model is broken.
The right question isn’t “what permissions do I need to make this work?” The right question is: who actually needs access to this, and what’s the blast radius if they’re compromised?
- The application needs to read the config. Does it need to write it?
- The service user needs execute access. Does it need root ownership?
- Do other processes on this machine need to read these files at all?
Most permissions problems aren’t about misconfigured numbers. They’re about not asking those questions.
The setuid, setgid, and sticky bit
Beyond the basic nine bits, Linux has three special permission bits worth understanding:
setuid (4): When set on an executable, it runs with the owner’s privileges, not the caller’s. This is why passwd can modify /etc/shadow even when run by a normal user — it runs as root temporarily. This is also why setuid executables need to be audited carefully.
setgid (2): On a file, similar to setuid but for group. On a directory, new files created inside inherit the directory’s group instead of the creator’s primary group. Useful for shared project directories.
Sticky bit (1): On a directory, users can only delete files they own, even if they have write access to the directory. /tmp uses this so every user can write there without deleting each other’s files.
These aren’t obscure flags. They’re the system expressing nuanced trust relationships.
The practical takeaway
When you see a permission string, read it as an answer to a trust question:
- Who owns this, and why?
- Who needs to read it?
- Who needs to run it?
- What’s the minimum access that makes this work?
The principle of least privilege isn’t just a security recommendation. It’s the whole point of the permission model.
If a process doesn’t need write access, don’t give it write access. If a file doesn’t need to be world-readable, don’t make it world-readable. Every unnecessary permission is a surface for things to go wrong quietly.
That’s not a Linux-specific rule. It’s a systems thinking principle. Linux permissions are one of the first places you practice it.
The goal isn’t to memorize the syntax. The goal is to understand what you’re deciding when you set a permission.
Part of my DevOps series — documenting real tasks with the commands, the reasoning, and the principles behind each decision.