Users and permissions — study guide
The concept's fragments, read in order.
Who is allowed to do what
Every file on a shared computer belongs to someone and carries rules about who may touch it. Permissions are those rules, and the operating system enforces them by asking one question on every access: is whoever is doing this allowed to do it?
The question comes in three shapes, because there are three things you can do to a file — read what is in it, change it, or run it as a program. Each time a process attempts one of them, the OS checks the file's rules first and refuses the attempts they do not permit. Nothing gets a pass for being convenient.
The rest of this concept is the machinery behind that check: who counts as a file's owner, how a group lets one rule cover many people at once, what the read, write, and execute bits actually grant, how to read them off a directory listing, and why the one account that skips the check entirely is the one to respect most.
Users and groups
A user is an identity the system knows — an account with a name and a number, its user id (uid), that the operating system uses to tell one person's actions from another's. Permissions are written in terms of these identities, so before the system can decide what you may do, it first has to know who you are.
A group is a named collection of users, and it exists so one permission can cover many people at once. Grant a group access to a file and every member gets that access without the file naming them one by one; add a person to the group later and they inherit it. It is the difference between writing a rule per person and writing a rule per role.
The identity is not only about logging in. Every running program runs as some user — it inherits an identity, and the system judges everything the program does against that identity's permissions. A program is exactly as powerful as the user it runs as, which is why the account a process runs under is a security decision, not a housekeeping detail.
Owner, group, other
Unix does not give every user a separate entry on every file — that would never scale. Instead it sorts the whole world into three classes for each file and writes one set of rules per class. The classes are the file's owner (a single user, usually whoever created it), the file's group (one group, whose members share a level of access), and other — everyone else on the system.
Each class carries its own read, write, and execute rules, and exactly one class applies to you. The system checks them in order — owner first, then group, then other — and the first class that describes you is the one that governs, even if a later class would have granted more. The three tiers usually run from most access to least — like a building's keycards in tiers: the owner's card opens every door, a team card opens the shared rooms, and a visitor pass opens only the lobby — because the owner is trusted most and the anonymous rest of the world least.
This is why a file can be fully editable by you, readable by your teammates, and off-limits to changes from everyone else, all at once, without listing a single name. One owner, one group, and a catch-all other cover every visitor a file will ever have.
Read, write, execute
Each permission class gets the same three bits, and their letters are r, w, and x — read, write, and execute. A bit is either granted or not; there is no middle setting. What makes them worth learning is that the same three bits mean different things on a file than they do on a directory.
On a regular file the meanings are the obvious ones. r lets you read the file's contents, w lets you change or overwrite them, and x lets you run the file as a program. A script or a compiled binary needs its x bit set or the system refuses to execute it, however readable it is.
On a directory the same letters shift. r lets you list the entries inside it — see the names. w lets you create, delete, and rename entries within it, which is why deleting a file depends on the permissions of its directory, not of the file. And x lets you enter the directory and traverse through it to reach what is inside; without it you cannot use the directory in a path at all, even when you are allowed to read its listing.
Decoding a mode string
Run ls -l and every entry begins with a ten-character string like -rwxr-xr--. It packs a file's whole permission picture into ten slots, and once you can read it you can read any file's access at a glance.
The first character is not a permission at all — it is the entry's type: - for a regular file, d for a directory, l for a symbolic link. The nine that follow are three rwx triples, one per class in a fixed order: owner, then group, then other. So -rwxr-xr-- is a regular file whose owner may read, write, and execute (rwx), whose group may read and execute but not write (r-x), and whose others may only read (r--). A dash in any slot means that bit is off.
The same nine bits are often written as three octal digits, because each triple is just a sum: read is 4, write is 2, execute is 1. Add the bits that are on and each class becomes one digit, so rwxr-xr-x is 755 and rw-r--r-- is 644. It is the same information the letters carry, compressed to three numbers.
Root, and why it's dangerous
One account is exempt from all of this. The root user — the superuser, uid 0 — bypasses permission checks entirely: it can read, change, or run anything on the system regardless of what the rwx bits say. The whole owner, group, and other machinery simply does not apply to it.
That power is occasionally necessary and routinely dangerous — like a master key that opens every door in a building: indispensable for the rare job that truly needs it, but reckless to carry on your belt for everyday errands. When you run a command as root, directly or through sudo, every safety net the permission system provides is switched off for that command: a mistake that would normally be refused as permission denied can instead delete or overwrite something it should never have reached. There is no second check waiting behind the first.
The discipline that answers this is least privilege: work as an ordinary user by default, and become root only for the specific step that genuinely needs it. The narrower the window in which nothing is stopping you, the smaller the damage when you are wrong — and on a real system, eventually you are wrong.
Permission denied, and keeping keys safe
Most of the time you meet permissions, it is through a single message: permission denied. Underneath it is almost always one of two mismatches — the file's mode does not grant the bit you need (no x on the script you are trying to run, no w on the file you are trying to save), or you are not the owner or a member of the group its rules were written for. The fix follows from the diagnosis: change the mode, or act as the right identity.
The same rules decide whether real software runs safely. Deploy a game server or an agent pipeline and you are making permission choices whether you notice them or not: which user the process runs as, which files it owns and may write, which it may only read. Grant it too little and it fails with the denied message; grant it everything by running it as root, and any flaw in it inherits the run of the whole machine.
The habit worth keeping is to give each program its own unprivileged user, let it own exactly the files it must write, and reserve root for setup rather than for running. It is the least-privilege idea again, at the scale of a whole service: the question is never only whether something works, but who is allowed to do what, and what happens when it goes wrong.