Linux File Permissions

Before you learn a single command, let's get the idea straight — because once the model clicks, the syntax is just shorthand for something you already understand.

Linux is a multi-user system. Even on your own laptop there are dozens of "users" — you, plus system accounts like root, www-data, and sshd that run services. If every account could read and overwrite every file, one compromised web server could rewrite your login program, and any user could read everyone else's private keys. That's not a system anyone would trust.

So Linux attaches a small, fixed rule to every single file and directory answering one question: who is allowed to touch this, and how?

Here's the picture to keep in your head. Think of each file as a room with three sets of keys:

• one key for the owner — usually the person who created the file;
• one key for a single group — a team of users (say, developers or www-data);
• one key for others — everyone else on the system.

And for each key, the system records what that key is allowed to do: read the room's contents, write (change) them, or execute (run the file, or enter the directory).

That's the entire model: three classes (owner, group, others) × three actions (read, write, execute) = nine bits on every file. Master those nine bits and everything else in this lesson is just two different ways of writing them down.

The place you see permissions is ls -l. Every line begins with a 10-character string that looks cryptic until you learn to read it in chunks — and there are only ever four chunks.

The first character is the file type. The next nine are three groups of rwx, in a fixed order: owner, then group, then others. Read left to right, you're reading "what kind of thing is this, and what may each of the three classes do to it."

Typing rwxr-xr-x gets tedious fast, so almost everyone writes permissions as a three-digit number instead — one digit per class. The trick is that each permission has a value, and you simply add them up within each class:

• r = 4
• w = 2
• x = 1

Why those numbers? They're the three bits of binary — 4, 2, 1 — so every combination of rwx produces a unique total from 0 to 7. Think of it as a little panel of three light switches per class, where the switches are worth 4, 2, and 1.

Work an example the slow way once and you'll never need to again. Take rwxr-xr-x:

• owner rwx = 4 + 2 + 1 = 7
• group r-x = 4 + 0 + 1 = 5
• others r-x = 4 + 0 + 1 = 5

…which gives 755. Going the other way is just as easy: to expand 644, split the digits (6, 4, 4) and turn each back into switches — 6 = 4+2 = rw-, 4 = r--, 4 = r-- → rw-r--r--.

chmod — short for change mode — is how you set those nine bits. It has two styles, and fluent admins use both depending on the job:

• Octal (absolute): you state the entire final mode as a number, e.g. chmod 755 file. It overwrites all nine bits at once, regardless of what was there before. Use it when you know exactly what the mode should end up as.
• Symbolic (relative): you adjust specific bits, e.g. chmod u+x file. You name a class — user, group, others, or all — an operator — + add, - remove, = set-exactly — and the permissions. Use it when you want to flip one thing without recomputing the whole number.

Let's build a worked-example ladder, from the everyday to the advanced.

Permissions decide what each class may do. Ownership decides who the owner actually is, and which group applies. They work together: a rwx for the owner is worthless to you if you're not the owner. chown (change owner) sets both — and because it can hand your files to another user, changing an owner generally requires root/sudo.

There's one more layer, and it explains some things you've probably already seen and wondered about (like how a normal user can change their own password, which lives in a root-only file). Beyond the nine rwx bits sit three special bits, written as a fourth, leading octal digit — so you'll see modes like 4755, 2775, 1777. Each one solves a specific real-world problem:

• SUID (value 4) on an executable — the program runs as its owner, not as whoever launched it. Think of it as a borrowed badge: /usr/bin/passwd is owned by root and SUID, so when you run it, it briefly acts with root's authority — just enough to update your entry in the root-only /etc/shadow — and nothing more. One tightly-controlled door instead of giving you the master key.

• SGID (value 2) on a directory — new files created inside inherit the directory's group instead of your default group. This is the magic that makes a team's shared folder stay shared: nobody has to remember to fix the group on every new file.

• Sticky bit (value 1) on a directory — even when everyone can write in it, only the owner of a file may delete that file. This is exactly how /tmp can be world-writable yet safe: you can create files there, but you can't delete mine.

Everything so far has been the permission check: the kernel compares who you are with the file's owner, group and nine bits. Root mostly walks straight past that check (strictly, root holds the CAP_DAC_OVERRIDE capability, which overrides it). But the mode is not the last word on a file. Every inode on ext2/3/4, XFS and Btrfs (and tmpfs on kernels from 6.0) also carries a small set of attribute flags, and the kernel enforces two of them separately from the permission bits, with no root override:

• `i`, immutable. Nobody may write to the file, delete it, rename it, hard-link to it, or change its metadata (mode, owner, timestamps). That includes root.
• `a`, append-only. The file can only be opened for appending. >> works. >, truncation, rename and delete don't.

ls -l and stat never show these flags, so a file can look like an ordinary -rw-r--r-- root root and still refuse root. You read them with `lsattr` and set them with `chattr`: +i sets a flag and -i clears it. They are not ACLs (getfacl) and not the user extended attributes that getfattr shows. Those are different mechanisms with confusingly similar names.

So who can clear the flag? A process that holds the `CAP_LINUX_IMMUTABLE` capability. An ordinary root shell does. Root is not exempt from the flag, but root can take it off, so the flag never stops an admin who means it. What it stops is everything else: a script's stray >, a config-management run, an rm -rf in the wrong directory, and any root process that has dropped that capability. A hardened service whose systemd unit sets CapabilityBoundingSet= without it is one example. Once a capability is gone from a process's bounding set, neither it nor its children can get it back, even as uid 0. (The access-control lesson covers capabilities: root's power split into about forty separate pieces.) Watch it happen:

These flags show up on both sides of an incident.

• Hardening and containment: pin what must not change while you work, such as /etc/passwd, /etc/shadow or an authorized_keys file mid-incident, and put +a on a log you need to be tamper-evident (clearing it first for rotation, as above).
• Detection: attackers know this trick too. A dropped cron job, systemd unit or SSH key pinned with +i makes your cleanup fail with an error that looks like a permissions problem, and the persistence survives. That is why lsattr belongs in a triage pass, run before you start removing things, and not only in a hardening checklist. The sweep looks like this:

Reading permissions is one thing; the knowledge sticks when your fingers do it. You have a real shell to the right — run this exact loop (create → inspect → change → re-inspect) and watch the string change each time. This is precisely the loop a "set the correct permissions" lab grades, so you're rehearsing the real thing.