Permissions: One Shared Tree, Who May Do What

One Tree, Many Owners: an Owner Label on Each File

Suppose a whole class shares one school computer. The file tree holds the slides I made, my friend's homework, and the config files the computer itself uses, all hanging together. With no rule at all, anyone could open my slides and change them, or wipe them out entirely. Just imagining it is unsettling. So the first thing the operating system does is stamp every file with an owner label. It writes down clearly whose file this is, who the owner is.

Tap a file to see its owner. Yours shows in gold; other people's and the system's show dimmed. Every file has an owner.

Now it is clear which file belongs to whom. But knowing the owner is not the end. A friend just opening my slides to look is a completely different thing from changing or deleting them. So an owner label alone is not enough; we have to split, more finely, exactly which actions are allowed on a file. What those actions are, we will see next.

Three Actions: Read, Write, Execute

The operating system sees exactly three things you can do to a file. First, read: looking into the file's contents. Second, write: changing the contents, or deleting them outright. Third, execute: if the file is a program, running it so it does its work. These three can be switched on and off separately. For example, a file might allow reading but block writing, so you can only look and not change it. And a program file runs only when execute is switched on.

Tap read, write, and execute to switch them on and off. On is green (allowed), off is red (blocked). The three are set separately.

Read, write, execute. Just these three switches already allow fairly delicate control. You can allow looking but block changing, or allow only running. But one thing is missing. When we say reading is allowed, allowed for whom exactly? Only the owner? Or every single person in the world? For the same file, the permission should differ depending on who is asking. Next, let us split up that who.

For Whom? Owner, Group, Others

The operating system sorts people into three groups. The first is the owner, the file's master in person. The second is the group, people bundled into the same team; think of it as the friends in your project group. The third is others, everyone outside that. And the three actions we just saw, read, write, and execute, are set separately for each of these three groups. So for the very same file, the owner can both read and write, the group can only read, and others can do nothing at all. A permission becomes a table woven across who and what.

Tap a cell to switch it on and off. The rows are owner, group, others; the columns are read, write, execute. Green is allowed, red is blocked. Same file, different rights per class.

Now, even for the same file, we can grant different rights to different people. That is a fairly fine-grained order. But here a tricky situation comes to mind. If every file is firmly locked to its owner, who installs a new program on the computer, or fixes things when someone forgets their password? It seems we need a special person who can open every lock. Next, let us meet that person.

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

That special person is the administrator. In English they are called root or superuser. The administrator skips over the ordinary permission rules. They hold a master key that can read, change, and run any file at all. Thanks to that, they can install new programs, repair broken settings, and reset a forgotten password. But this key is also frightening. A single mistake as the administrator can break the whole system. So you normally live as a plain user and borrow administrator power only when it is truly needed.

As a plain user, try to open the locked file. It is blocked (red). Switch to administrator and try again. With the master key it is allowed (green).

The locked door was blocked for the plain user and opened for the administrator. Because of this master key, the computer can be cared for and fixed. At the same time, you can probably feel why you should not walk around as the administrator carelessly: every lock goes powerless. The order called permissions keeps a plain user inside a fence, and gives the administrator the power to step over that fence while treating it as a heavy thing. Now let us put the whole picture together at once.

In Summary: Who Times What, and the Administrator Above

Put on one page, it goes like this. To guard a shared tree, the operating system stamps every file with an owner label and hangs a small table on it. Across the top is what, namely read, write, execute. Down the side is who, namely owner, group, others. Each cell is green if allowed, red if blocked. And above this whole table stands the administrator, holding the master key. A plain user does only as much as the table allows; the administrator skips the table and does anything. The tidy tree from last lesson has now become a tree we can share safely.

Tap the cells to explore the permission table. Then switch to administrator. The master key turns the whole table to allowed at once.

But here a curious gap shows up. Earlier we said the operating system walls programs off from touching hardware or the disk directly. If so, how does my program open even a file it is allowed to read? In truth, it cannot open it itself. Instead it has to ask the operating system politely. In the next lesson we begin the story of system calls, the official counter where a program asks the operating system to do work. Checking permissions happens at that very counter.