How do file permissions work

One Tree, Many Owners: Every File Gets an Owner Label

Picture a whole class sharing one school computer. Its file tree holds the slides I made, the homework a classmate turned in, and the settings files the computer itself relies on, all hanging from the same branches.
With no rules, anyone could open my slides and rewrite them or delete them outright, or poke at a settings file until the computer would no longer start.
So the first thing the operating system does is attach an owner label to every file. For each file it records who made it and whose it is.

Tap the three files one by one to reveal their owners. Your file shows in gold, your classmate's and the system's show dimmed, and not a single file is without an owner.

Now it is clear which file belongs to whom. Knowing the owner is not enough, though.
A classmate opening my slides just to look is a very different thing from editing or deleting them. I might be happy to let people look and still not want anyone changing a word.
So for each file we need to split up, more finely, which actions are allowed.

Three Actions: Read, Write, Execute

The operating system boils everything you can do to a file down to three actions. Read means looking at what is inside. Write means changing the contents or deleting them. Execute applies when the file is a program, and means running it.
Each of the three can be switched on or off on its own. Leave read on and turn write off, and the file can be looked at but not changed.
A program file with execute switched off simply will not run.

Tap read, write, and execute to switch each one on and off. At first only read is on, so the file can be viewed and nothing more. On turns green (allowed), off turns red (blocked), and flipping one leaves the other two alone.

With just three switches, read, write, and execute, you can already get quite precise. You can allow looking but forbid changing, or allow running and nothing else.
One thing is still missing, though. If reading is allowed, allowed for whom? Only the owner, or everyone in the world? The answer changes everything.
The same file should grant different things depending on who is asking.

For Whom? Owner, Group, Others

The operating system sorts people into three classes. The first is the owner, the person the file belongs to. The second is the group, the people bundled together as one team; think of the classmates in your project group. The third is others, meaning everyone else.
Then read, write, and execute are set separately for each of the three. The starting state of the table below is one example: the owner can do all three, the group can read and execute, and others can only read.
So a permission turns into a single table that crosses who (three rows) with what (three columns).

Each tap on a cell flips it between allowed (green) and blocked (red). The rows are owner, group, and others and the columns are read, write, and execute, so one file can grant each class something different.

Now even a single file can hand out different rights to different people. That is a fairly fine-grained order.
But a tricky question comes up. If every file is locked tight to its owner, who installs new programs on the computer, or sets a new password when someone forgets theirs?
It looks as if we need one special person who can open every lock.

The Administrator (Root): a Master Key Above the Rules

That special person is the administrator. On Linux and similar systems the account is called root, or the superuser. The administrator skips the permission table altogether, holding a master key that can read, change, and run any file.
That is how new programs get installed, broken settings get repaired, and forgotten passwords get reset.
The same key is dangerous, though. One wrong command typed as the administrator can wreck the whole system. So people normally work as a plain user and borrow administrator power only for the moment they truly need it.

First, as a plain user, try to open your classmate's locked file: it is blocked (red). Switch to root and open it again, and the master key lets you in (green).

The locked file stayed shut for the plain user and opened for the administrator. Because that master key exists, someone can always look after the computer and fix it.
It also shows why nobody should wander around as the administrator for no reason: in front of that key, every lock loses its power.
The order we call permissions keeps plain users inside a fence and gives the administrator the strength to step over it, on the understanding that this strength is used with care.

In Summary: Who Times What, with the Administrator Above

On one page, it looks like this. To protect a tree that many people share, the operating system attaches an owner label to every file and hangs a small table on it.
Across the top is what: read, write, execute. Down the side is who: owner, group, others. Each cell is green when allowed and red when blocked.
Above the whole table stands the administrator with the master key. A plain user can do only what the table allows, while the administrator skips the table and can do anything. The tidy tree from the last lesson has become a tree many people can share safely.

The table lays out in green and red what the owner, group, and others may do. Press the button below to switch to root, and the master key turns the whole table to allowed (blue) at once.

Yet a strange gap appears here. Earlier we saw the operating system wall programs off so they cannot touch the hardware or the disk directly.
So how does my program open even a file it is allowed to read? The truth is that it cannot open the file on its own. It has to ask the operating system to do it.
The next lesson is about system calls, the official counter where a program hands work to the operating system. Looking up this table and checking permissions happens at that same counter.