How does the classic Linux permission model decide who may do what with a file?

Every file has one owner and one group; permissions are set separately for three classes (user, group, others), each with read, write and execute.

A permission always has two parts: the resource (a file or directory) and the operations allowed on it. Linux keeps this deliberately small. Each file carries:

• an owner (a UID) and a group (a GID),
• three permission triplets, one per class:
  • user (u): the owner,
  • group (g): members of the file's group,
  • others (o): everyone else,
• and in each triplet the bits r (read), w (write) and x (execute).

When a process opens a file, the kernel compares the process's UID and GIDs with the file's. It picks exactly one class, the first that matches in the order user, group, others, and only that triplet counts. So if the owner has r-- and others have rw-, the owner still cannot write. Classes are not added up.

Compared with Windows NTFS ACLs (any number of entries per user or group, allow and deny), this is coarse: one owner, one group, everyone else. That simplicity is why groups carry most of the access design on Linux.

Go deeper:

• Wikipedia: File-system permissions — the Unix model next to ACLs, with notation examples.
• ArchWiki: File permissions and attributes — a practical reference with many worked ls -l examples.