How do Unix file permissions work, including directories, setuid, setgid and the sticky bit?

TL;DR: Each file has an owner, a group and nine bits: read, write and execute for owner, group and others. The kernel picks exactly one of those three sets (owner if you own it, else group if you are in it, else others) and checks the operation against it. On a directory, read lists names, write creates and deletes entries, and execute lets you traverse it to reach anything inside. The special bits change identity or deletion rules: setuid runs an executable with the file owner's user ID, setgid does the same for the group (and on directories makes new files inherit the group), and the sticky bit on a directory stops users deleting each other's files, as in /tmp.

How to approach it

Explain the evaluation rule first, because candidates who know the bits often get the rule wrong. Then directories, because that is where most surprises live. Then the special bits and the attack surface they create. Mention ACLs, capabilities and mandatory access control as the layers above.

A strong answer

Reading the bits. -rw-r----- alice finance report.csv means alice can read and write, members of finance can read, everyone else gets nothing. In octal, read is 4, write 2, execute 1, so that file is 640. A new file's mode is the requested mode with the process's umask bits removed; a umask of 027 turns a requested 666 into 640.

The evaluation rule. The kernel checks the process's effective user ID against the owner; if it matches, only the owner bits apply, even if the group or other bits would allow more. Otherwise, if any of the process's groups matches the file's group, only the group bits apply. Otherwise the other bits apply. So ----rwxrwx owned by alice denies alice everything while granting strangers full access. Root bypasses read and write checks (and execute, if any execute bit is set), which is why so much of Linux security is about not being root, and about capabilities that split root apart.

Directories.

Two consequences that come up in reviews. First, deleting a file needs write on the directory, not on the file. A world-writable directory lets anyone delete or replace anyone's files, which is why shared directories need the sticky bit. Second, to read /a/b/c.txt you need execute on /, /a and /a/b, plus read on the file; a directory with execute but not read lets people open files whose names they already know.

The special bits.

• setuid on an executable: the process runs with an effective user ID equal to the file's owner. passwd is setuid root so an ordinary user can update the password database it could not otherwise write. Every setuid-root program is privileged code that reads attacker-controlled input (arguments, environment, files, signals), so a bug in it is a privilege escalation. Linux ignores setuid on interpreted scripts because of race conditions in starting the interpreter.
• setgid on an executable runs with the file's group; on a directory it makes new files inherit the directory's group, which is useful for shared project directories.
• sticky bit on a directory (drwxrwxrwt on /tmp): only the file's owner, the directory's owner or root may delete or rename an entry. It stops deletion and replacement of other users' files. It does not stop someone from creating a file with a name your program is about to use, which is why predictable temporary file names remain dangerous.

The layers above. POSIX ACLs add named users and groups beyond the single owner and group. Linux capabilities split root's powers into units such as CAP_DAC_OVERRIDE. Mandatory access control (SELinux, AppArmor) applies policy that even the file's owner, and often root, cannot override. Permissions are discretionary: the owner can loosen them, which is exactly what a compromised process running as the owner will do.

How this is audited. find / -perm -4000 -type f lists setuid files; each one should be justified and patched. World-writable files and directories without the sticky bit, writable files in PATH, and writable scripts run by root's cron jobs are the classic findings.

What interviewers probe next

• "A file is mode 000 and owned by you. Can you read it?" Not until you change its mode, which you can, because the owner can always chmod. Root can read it regardless.
• "Why is a setuid-root program that calls system() dangerous?" It runs a shell that honours attacker-influenced environment and PATH, so the attacker chooses what runs as root.
• "What is the difference between real and effective user ID?" Real is who started the process; effective is what permission checks use. A setuid program can drop back to the real ID once it has done its privileged step.

What if?

How it's scored

Weak: Recites rwx and octal, cannot explain directory execute or the sticky bit.

Hire: States the single-set evaluation rule, explains directory semantics, setuid and the sticky bit, and knows setuid programs are an escalation surface.

Strong Hire: Adds umask, real versus effective IDs, why deletion depends on the directory, what the sticky bit does not stop, how to audit setuid and writable paths, and where ACLs, capabilities and MAC sit.

Common mistakes

• Thinking owner, group and other permissions add together.
• Believing write on a file is needed to delete it.
• Treating the sticky bit as protection against temporary-file attacks.
• Forgetting that the owner can always change permissions.