2. Users, groups, and why permissions exist

Description

By the end of this lesson you will be able to diagnose your full identity in front of the operating system with four commands (whoami, id, groups, who), tell apart the three permission classes Unix applies to any file — owner, group, and others — and explain, with technical arguments and not superstition, why an all-powerful account called root exists and why you do not work as that account every day.

This is not manual theory. The day you SSH into a company server — shared with nine other developers — or the day a Docker container runs a process under a different user than yours, you are going to need to know how to read who every identity involved is. Without this model, every Permission denied feels like a random system bug, and almost every junior's instinctive reaction is "I'll slap sudo on everything until it works" — a reaction that costs little on a personal laptop, but on a real shared server can overwrite someone else's work or open a security hole someone else is going to pay for.

Connection to the module: the previous lesson mapped out the module around three errors, and Permission denied was the first. This lesson is that error's root cause: without users, without groups, and without root existing, there would be nothing for a permission to protect. You are not going to touch chmod yet, or decode drwxr-xr-x letter by letter — that is exactly what comes in the next lesson. Today's goal is understanding the model before touching the mechanism.

Your laptop is a building with tenants, not an empty house

Imagine an apartment building. Every tenant has the key to their own apartment — and only their own. Tenants on the same floor share an additional key for a common room on that floor: laundry, terrace, whatever it is. And there is a third category, the broadest one: anyone else who enters the building — a delivery person, a visitor — has no key to any apartment or any common room, unless someone lends them one. The building also has a superintendent with a master key that opens absolutely everything. Nobody lives their daily life as the superintendent: it is an identity reserved for specific maintenance tasks, not for inhabiting the building.

Unix was designed in the 1970s for exactly this scenario, but with computers: mainframes dozens of people used at the same time from different terminals. The system needed to know, for every file and every process, who owned it and who else could touch it. That multiuser design was never abandoned. Even though today you are the only person sitting in front of your laptop, the operating system still treats it like that building: there are multiple user accounts already created before you ever touched the keyboard — service accounts that run system processes — and every file on your disk belongs to someone and to a group, exactly like on a server with a hundred real users.

Three pieces make that model work:

• User: an identity with a name and an internal number (the UID, user ID). The system does not think in names, it thinks in numbers — the name is just the readable label shown to you.
• Group: a collection of users that share a certain level of access. Every user has a primary group (think of it as the building's floor) and can also belong to secondary groups (think of a club inside the building you joined later: the gym, the parking garage).
• root: the account with UID 0. The kernel recognizes it by that number and, seeing it, skips permission checks entirely. It is the superintendent's master key — and for the same reason nobody lives as the superintendent, you do not work as root day to day. Later in this module you are going to see exactly when borrowing that power with sudo is the right tool and when it is a sign something else is wrong; for now, keep this: root exists because someone has to be able to do everything, and you are not that someone all the time.

Worked example

Four commands tell you, with different levels of detail, who you are to the system right now.

whoami
id
groups
who

What to expect (typical output on a Linux distribution; on macOS the numbers and group names change, but the shape is the same):

$ whoami
dev

$ id
uid=1000(dev) gid=1000(dev) groups=1000(dev),27(sudo),999(docker)

$ groups
dev sudo docker

$ who
dev      pts/0        2026-07-21 09:14 (203.0.113.20)

Read it from the outside in:

• whoami answers a single question: which user am I right now? Nothing more. It is the minimal version, meant for use inside scripts that need a single line of text.
• id is the full record: your UID (1000), your primary group or GID (1000, which here matches your own name — many distributions create a private group identical to the user the moment it is created) and the full list of secondary groups you belong to. Here sudo and docker are not decoration: belonging to sudo is literally what enables you to use that command, and belonging to docker is what lets you run containers without typing sudo before every one.
• groups is a shortcut: the same group list from id, without the numbers, for when you only care about the names.
• who answers a different question from the other three: not "who am I," but "who is logged into this machine right now" — every active session, with its terminal and, if you connected over SSH, the address you came in from. On your laptop you are going to see only your own session; on a shared server you are going to see one line per person connected at that moment, which is exactly the scenario the command was designed for.

Every file's three classes: owner, group, others

The same user-and-group model repeats, file by file, in three fixed categories Unix applies with no exceptions:

1. Owner: the specific user who owns the file — normally whoever created it.
2. Group: the group associated with the file. Any user belonging to that group inherits the access level the file assigns to the "group" category, no matter who they individually are.
3. Others: everyone else — any system user who is neither the owner nor part of the file's group. It is the building's delivery-person category: they exist, they might need to enter, but by default they have no key at all.

You already saw in the previous module that ls -l prints a column shaped like drwxr-xr-x. That string describes exactly these three classes — three character blocks, one per category — but decoding each letter in detail and changing them with chmod is the entire next lesson's topic. All you need today is to recognize that owner, group, and others are not a detail on some screen: they are Unix's complete access-control model, applied to every single file on your disk, always in that order.

Why "Permission denied" is a sign the system is working

When the system hands you Permission denied, it is easy to feel it as an arbitrary obstacle. It is the opposite: it is the kernel correctly applying the three classes you just saw. Without that check, any user on a shared server could read, modify, or delete any other user's files just by typing the right path — the isolation that lets ten different people use the same machine without stepping on each other would stop existing.

That isolation rests on an idea you are going to see repeated throughout the module, today in its simplest form, before a single command exists to apply it: the principle of least privilege. It says, essentially, that every identity — a user, a process, a script — should have exactly the access it needs to do its job, not one permission more. It is not a paranoid security rule: it is damage math. If a compromised process or a buggy script runs with access to the whole disk, the potential damage is the whole disk. If that same process only has access to the folder it actually needs, the possible damage is bounded to that folder. root exists precisely because some identity needs full access for administrative tasks — but by that same logic, no everyday work should be done under that identity, the same way the building's superintendent does not lend the master key to a tenant just because they lost their own.

Common mistakes

"It's my computer, so I should be able to do whatever I want all the time" (conceptual). What happens: the student interprets every Permission denied on their own laptop as a system error, reasoning "this machine is mine." Why it happens: it confuses legal ownership of the hardware with the operating system's identity model — they are different things. The system does not know or care whose laptop it is; it only knows which UID asked for which access to which file. How to spot it: if your automatic reaction to any permissions error is "but it's my computer," that is the symptom. How to fix it: remember that even on your own laptop multiple accounts exist (yours, root, service accounts) and that the model treats your machine exactly like it would treat a server with a hundred real users — the protection exists for when something (a script, a compromised process, a mistake of yours) tries to do more than it should, no matter whose hardware it is.

Confusing the username with the UID. What happens: when copying files from another machine, restoring an old backup, or reading a Docker container's mounted volume, ls -l shows a number (say 1005) in the owner column instead of a name. The student assumes the file is broken or corrupt. Why it happens: the filesystem does not store the text "ana" inside the file — it only stores the UID number. ls translates that number into a readable name by checking the local user database; if that machine has no user registered with that UID — because the file came from another system, because the original user was already deleted, or because a container uses a different UID mapping — there is no name to show, and the raw number shows up. How to spot it: you see a number where you expected a name in ls -l's output. How to fix it: it is not corruption — it is real information. You can try id 1005 to see whether that UID corresponds to any existing user on your machine; if the command finds nobody with that identifier, you confirm the original owner does not exist locally, and you know the problem is not the file but the context it came from.

Looking only at groups's first entry and ignoring the rest. What happens: the student runs groups, sees a list, and only pays attention to the first name — normally the primary group, almost always matching their own user — assuming the rest are decorative noise. Why it happens: the first value seems "the important one" because it matches the username, and the rest go unnoticed. How to spot it: if someone asks you "can you run Docker without sudo?" or "do you have permission to use sudo?" and you need to go check instead of knowing the answer by heart from looking at your own groups, that is the sign. How to fix it: treat every secondary group in the list as a real, active capability, not metadata: belonging to sudo is what lets you use sudo; belonging to docker is what lets you use Docker without it. groups's full list is, literally, the list of capabilities you have active right now.

Exercises

1. Run whoami, id, groups, and who in your own terminal. With the real output in front of you, answer: does your primary group have the same name as your user? Which secondary groups do you belong to, and what real capability does each one give you?

See solution

There is no single correct answer because it depends on your machine — the exercise wants you to interpret your own output, not compare it against a fixed value. If your system follows the convention of creating a private group per user (common on Debian, Ubuntu, and derivatives), your primary group is going to match your username. For every secondary group that shows up (for example sudo, docker, wheel, admin), the right question is not "what is it called" but "what can I do because I belong to it that I could not do otherwise?" This works because the exercise's purpose is to get you to stop seeing groups as decorative text and start reading it as a list of active capabilities.

2. A teammate sends you this id output from their own account and asks whether they can run sudo apt update without the system rejecting it:

uid=1002(sam) gid=1002(sam) groups=1002(sam),999(docker)

Can they? Justify your answer using only this line.

See solution

They cannot — at least not without someone enabling it for them first. sam's groups list is sam (their primary group) and docker; sudo or any equivalent administrative group is nowhere in it. The ability to use sudo does not depend on "being a valid system user" — it depends, on most Linux distributions, on specifically belonging to the sudo group (or wheel, depending on the distribution) and having a rule that authorizes it. This works because sudo is not a universal permission every user has: it is a capability granted by group membership, exactly like any other.

3. Listing a shared folder on a server, you see this line:

-rw-r--r-- 1 1005 1005 2048 Jul 20 10:03 report.csv

Instead of a username, 1005 shows up twice. What explains this, and what would you do to confirm it?

See solution

1005 is the numeric UID (and GID) of the file's original owner, and ls -l could not translate it into a readable name because this machine has no user registered with that identifier — it could be that the file arrived from another server, that the original user was deleted from this machine after creating the file, or that it comes from a container with a different UID scheme. To confirm it, you would try resolving that UID against the local user database (for example with id 1005); if it finds no matching user, you confirm the owner simply does not exist on this system — the file is not broken, it just references an identity foreign to this machine. This works because the filesystem never stores names, only numbers; the name is a translation that depends entirely on a local entry existing for that number.

4. Explain in your own words why root should not be your everyday work account, even though you have the password and can technically log in as root at any time.

See solution

Because root (UID 0) makes the kernel skip permission checks entirely: any process you run as root has unrestricted access to the whole system, with none of the protection the three classes — owner, group, others — exist to provide precisely to bound the possible damage from a mistake or a compromised process. If you work day to day as root, a simple typo in a command, or a buggy script, has the same destructive reach as a deliberate attack: the whole disk, no exceptions. Working under your normal user, that same mistake stays bounded to what your user can touch. This works because it is exactly the principle of least privilege applied to yourself: use the access level your task needs, not the maximum available, and borrow the maximum only when a specific task genuinely requires it.

Summary and next step

Today you saw that your laptop, even though only you use it, follows the same multiuser model Unix was designed with for shared mainframes: every identity has a user (with its UID), belongs to a primary group, and can have secondary groups, and whoami, id, groups, and who are the four ways to check that identity with different levels of detail. You also saw that every file applies that same model in three fixed classes — owner, group, others — and that root (UID 0) is the only identity the kernel exempts from those checks, exactly why it is not your everyday work account. Permission denied is not the system being annoying: it is the principle of least privilege working right in front of your eyes.

Before moving on you should be able to: run the four identity commands and interpret every field of their output unassisted; explain from memory what the three permission classes are without having seen the rwx symbol yet; and explain, in your own words, why seeing a number instead of a name in ls -l does not mean a file is damaged.

What you learned today — that every file distinguishes owner, group, and others — is exactly the structure you are going to read character by character in the drwxr-xr-x string in the next lesson, when you connect that model to chmod and learn to change it yourself, both in symbolic and octal notation.

Resources

• id invocation — GNU Coreutils Manual — official reference for all of id's options, including the difference between real and effective UID.
• who invocation — GNU Coreutils Manual — what information who exposes about every active session on the system.
• groups invocation — GNU Coreutils Manual — official documentation for groups and its relationship to id -Gn.
• id(1) — Linux manual page — id's canonical man page, with detail on how it resolves names and numbers.
• Superuser — Wikipedia — history and definition of the root/administrator account on Unix systems and why the kernel treats it as a special case.