Unix Access Control: Inodes, Permissions, and setuid

Contents

The core access-control model

Access control is a protection wall with a guarded gate. A subject cannot directly reach a resource; a reference monitor intercepts the request and checks the policy.

Complete mediation: every access to every protected resource must pass through the check. An unguarded path defeats the model even if the main path is correct.

Access matrix

Rows represent subjects, columns represent objects, and each cell contains the rights that its row subject has over its column object.

Users, principals, and subjects

High-level policy is usually about people, but Unix grants rights to accounts and processes perform the accesses. The operating system therefore needs a reliable way to determine which principal a process represents.

• One human may have multiple principals, such as separate ordinary and administrative accounts.
• Each principal should map to one human so actions remain attributable.
• Unix identifies accounts with UIDs; UID 0 traditionally denotes the superuser.
• Groups let a policy name collections of principals more succinctly.

Objects in Unix

An object is anything on which a subject can perform a mediated operation. Files, directories, memory segments, and even processes can be objects.

Key distinction: a directory is not just a container. It is a file-like object that maps names to inode numbers, so its permission bits govern name lookup and entry modification.

Unix permission semantics

Unix first selects one permission class: owner if the effective identity matches the owner; otherwise group if the process belongs to the file’s group; otherwise other. It does not combine bits from several classes.

Reason about the operation, not just the target

• Reading /d1/d2/f3 needs x on d1 and d2, then r on f3.
• Writing that file changes its contents, so it needs path traversal plus w on the file.
• Deleting it changes the parent directory entry, so it normally needs w+x on d2, not permission on f3.
• Renaming within one directory likewise changes directory entries.

Common surprise: directory r lets you list names, while directory x lets you use a name you already know. Either permission can exist without the other.

The special permission bits

These bits modify normal behavior; they are not a fourth set of rwx rights. Their meaning also depends on whether the object is a file or directory.

Reading s and S in ls -l

ls -l displays setuid or setgid in the position normally used for x. The letter’s case tells you whether execute/search is also present.

Why can ls -asl a say “Permission denied”?
The -a, -s, and -l options change the requested output, not the caller’s permissions. If a is a directory, ls needs directory r to enumerate its names and directory x to search those names and obtain each entry’s metadata. Without applicable x, a long listing may show names but fail to inspect entries, producing “Permission denied” or question marks.

• The special s bit does not independently grant read, write, or traversal.
• Lowercase s includes x, but only for its displayed class: owner or group.
• If the process is neither the owner nor a member of the directory’s group, the other bits apply; a group s does not help.
• Every parent directory in the pathname must also grant the applicable class x.

Process identity and setuid

fork copies all three UIDs to the child. A normal exec replaces the program but preserves the UIDs. Executing a setuid file preserves RUID while changing EUID and saved UID to the file owner’s UID.

Why setuid programs are risky

Some tasks require authority not represented by ordinary file permissions—for example, changing protected account data in a controlled way. A setuid-root program can provide that controlled operation, but a bug may expose far more root authority than the task needs.

• Keep the privileged code path small.
• Validate all untrusted input before using privilege.
• Drop privilege as soon as the privileged operation is complete.
• Prefer permanent drops when the privilege will never be needed again.

Access-control design checklist

Use this sequence when analyzing a new system. A complete answer covers both policy and enforcement.

1. Objects: What resources need protection, and how are they organized?
2. Subjects and principals: Who requests access, and on whose behalf?
3. Human mapping: How are people authenticated and made accountable?
4. Operations: Which rights can subjects exercise on each object?
5. Policy storage: Where are permissions recorded, and who may update them?
6. Mediation: Where is each request intercepted, and are all paths covered?
7. Residual threats: What assumptions or bypasses could still defeat protection?

Common pitfalls

• Confusing a human user, account/principal, and process/subject.
• Putting objects in matrix rows or subjects in columns.
• Thinking complete mediation means checking only the first access.
• Treating a filename as the file itself rather than a directory-to-inode mapping.
• Giving directory r, w, and x their regular-file meanings.
• Assuming permission on a file controls deletion of its directory entry.
• Combining owner, group, and other permission classes.
• Assuming s is an extra access right; it marks setuid/setgid and occupies an execute position.
• Forgetting that lowercase s includes execute/search while uppercase S does not.
• Saying RUID normally determines access; EUID usually does.
• Thinking a temporary privilege drop removes the privileged saved UID.
• Calling setuid itself safe or unsafe without examining the privileged code path.

Applied questions and scenarios

Select an answer for each question, then check the highlighted choices.

Worked scenarios