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.

On a directory, r lists the names, w creates, renames and deletes entries, and x lets you enter it and reach the files inside.

A directory is a list of names pointing to files, and the bits apply to that list. Two consequences:

• Deleting a file is a write on its directory, not on the file. A user with w on the directory can delete a file they cannot even read. The sticky bit exists to close exactly this gap.
• r without x is nearly useless: you see the names but cannot open anything. x without r gives a "blind" directory: you can open a file only if you already know its name.

Go deeper:

• ArchWiki: File permissions and attributes — includes a table of what r, w and x allow on directories.