How Linux decides who can read, write, and execute — from the three permission bits through ACLs and the sudo and PAM machinery behind every login.
6 topics
Every file access on a Linux server passes one check: does this process, running as some user with some set of groups, have the rights the operation needs? This chapter covers the machinery behind that check, starting with the UIDs and GIDs that identify accounts and ending with the privilege-escalation paths that let a non-root user run a single command as root.
The classic model is three permission bits — read, write, execute — applied to owner, group, and everyone else, and it covers most cases. Where it falls short, ACLs grant per-user rights, the setuid and setgid bits change which identity a process runs as, and sudo with PAM gates who may become root and how. By the end you should be able to read any ls -l line, fix a "permission denied" without resorting to chmod 777, and reason about what an attacker gains from a setuid binary.
Who gets which access
Owner (u)
The user that owns the file. The kernel checks this triad first; if you are the owner, only the owner bits apply — group and other are not added on top.
Group (g)
The file's group. Checked only if you are not the owner but belong to the group. Supplementary group membership is how shared access is granted.
Other (o)
Everyone else. The last fallback triad. A too-generous "other" is how files end up world-readable or world-writable by accident.