Who is allowed to do what

A multi user system must stop one user reading another's files, and stop any program doing more than it should. Most of that rests on a small number of mechanisms.

Users and permissions

Every process runs as a user, and every file records an owner, a group and three sets of permissions.

$ ls -l report.txt
-rw-r-----  1 priya finance  4096 Sep 24 11:02 report.txt
 │└┬┘└┬┘└┬┘
 │ │  │  └── others: nothing
 │ │  └───── group finance: read
 │ └──────── owner priya: read and write
 └────────── a regular file

On a directory the bits mean something different and it catches people out: read lists the names, write creates and deletes entries, and execute allows entering it and reaching things inside. A directory with execute but not read lets someone open a file whose name they already know while not being able to list the contents.

Root, and why sudo exists

The root user bypasses permission checks entirely. So the rule is to run as root as rarely and as briefly as possible, and sudo exists to make elevation explicit, logged and per command rather than a session you forget you are in.

A web server running as root turns a file read vulnerability into total system compromise. The same bug in a process running as www-data exposes what www-data can read.

setuid

A program can be marked to run as its owner rather than its caller. passwd needs this: an ordinary user must change their own password, which means writing to a file only root may write.

It is also a permanent hazard. A setuid root binary with a bug is a direct route to root for anyone who can run it, which is why the list of them on a system should be short and examined.

$ find /usr/bin -perm -4000

Beyond the classic model

Owner, group and others is coarse. Modern systems add:

ACLs, granting specific permissions to specific users beyond the three classes.

Capabilities, splitting root's power into pieces. A program needing to bind to port 80 can be given that one capability instead of being root.

Mandatory access control (SELinux, AppArmor), where a policy constrains processes regardless of file permissions, so a compromised web server cannot read files it has permission to read but no business reading.

The principle underneath

Least privilege: every process gets exactly what it needs and nothing more. Every mechanism above is a way of making that achievable, and the reason is always the same. Software has bugs, so the question is not whether something will be compromised but how much it can reach when it is.