On Linux, a file is owned by user alice and group devs with mode 0466 (r--rw-rw-), and alice is a member of devs. Can alice write to that file, and why?

## The check is a selection, not an accumulation Most people carry a mental model in which permission grows as you match more categories: you are in the group, so you get the group's rights *added* to yours. That model is wrong, and this scenario is the standard way interviewers expose it. The kernel's discretionary access check works like this, in order: 1. If the process's effective UID equals the file's owner UID → **use the owner triad and stop**. 2. Else, if the effective GID or any supplementary group of the process equals the file's group GID → **use the group triad and stop**. 3. Else → **use the other triad**. Exactly one branch runs. There is no union, no maximum, no fallback to a more generous class if the selected one denies the operation. Applied to the example — owner `alice`, group `devs`, mode `r--rw-rw-`: | Who | Class selected | Effective rights | |---|---|---| | alice | owner | read only | | bob, member of devs | group | read and write | | carol, unrelated | other | read and write | The owner has strictly less access than anyone else on the system. That is not a bug; it is the specified behaviour, and it is occasionally used deliberately as a self-protection measure against accidental overwrites. ## Why it is designed this way A union model would make it impossible to express "this class specifically may not do X". If matching more categories always meant more rights, you could never restrict the owner while permitting the group, and a mode's meaning would depend on group membership you cannot see from the mode. The select-one rule keeps each triad an exact statement about that class, which is also what makes a mode readable at a glance. ## The escapes Two things sit outside this rule. **Ownership is not the same as access.** Alice cannot write the contents, but she *can* change the mode, because the right to `chmod` a file belongs to its owner regardless of the permission bits. The restriction is therefore advisory against accident rather than a security boundary against the owner: ``` $ echo hi > /tmp/odd bash: /tmp/odd: Permission denied $ chmod u+w /tmp/odd # allowed: alice owns it $ echo hi > /tmp/odd # now fine ``` **Privileged processes bypass the check entirely.** Root — more precisely, a process holding the capability that overrides discretionary access checks — is not subject to the triad selection at all, which is why testing a permissions theory as root proves nothing. Always reproduce the failure as the account that actually hit it. ## How it shows up in the real world It is rarely mode `0466` in production; the realistic shapes are: - **A service account that owns a directory whose owner bits are tighter than the group bits.** A deployment step wrote `chmod 0470` intending to give the group access, and the service — which owns the directory — quietly lost write access. Adding it to another group changes nothing, because the owner branch is what runs. - **A shared area where an account was added to the right group but is also the file owner.** Group membership is the fix people try first, and it has no effect for files that account already owns. The diagnostic instinct to build: when a permission failure looks impossible given the group membership, check whether the failing account is the **owner**. If it is, group membership is irrelevant to the outcome and you must look at the owner triad. A further practical note: group membership is established when the process's credentials are set, typically at login. Adding a user to a group does not change the supplementary groups of processes that are already running, so an already-open session may still be judged by the other class even after the membership change lands. That is a separate trap from the one in this question, but it appears in the same conversations. ## The one-sentence answer No — the kernel selects one class, ownership wins that selection, and the owner triad here grants read only; alice's `devs` membership is never consulted, though she may `chmod` the file because she owns it.