Filesystems · foundation
Ownership and groups
A Unix filesystem object records an owning user ID and group ID. A process's effective user and group credentials determine which traditional permission class and other authorization rules apply to its access request.
Why it matters
Correct ownership lets teams share files without making them public and lets services run with limited identities. Wrong owners or groups commonly break deployments, containers, and shared directories.
Mental model
How to reason about ownership and groups
Files store numeric IDs, while account databases translate those IDs into displayed names. During a mode-bit check, an owner match selects owner bits; otherwise a matching file group or supplementary group selects group bits; otherwise other bits apply.
Analogy
Ownership is like a document naming one custodian and one department. The access rule first asks which relationship the visitor has, then reads that relationship's permissions rather than choosing the most generous row.
Examples
See the boundary, not just the happy path
Worked example · Inspect process identities
idid reports the invoking process's user and group identities, including supplementary groups. Those numeric credentials participate in filesystem access checks.
Worked example · Assign a project group
chgrp developers shared.logchgrp changes the file's group ID when permitted. Whether members can then read or write still depends on the group mode bits and any additional ACLs or security policy.
Useful contrast · Ownership is not permission
chown app:app config.ymlThis selects the owner and group identities but does not itself define rwx access. chmod changes traditional mode permissions; chown changes who the owner and group classes refer to.
Common mistakes
Misconceptions to remove early
Choosing the most permissive matching class
Traditional checks do not compare all three classes and pick the broadest. If the process matches the owner, owner bits are used; a denied owner bit is not rescued by permissive other bits.
Assuming displayed names are stored in every inode
Filesystems normally store numeric user and group IDs. Name-service changes can alter the displayed name without rewriting the inode.
Quick check
Can you predict the result?
1. If a process's effective UID matches a file's owner, which traditional permission bits are checked?
- • The owner permission bits.
- • Whichever of owner, group, or other is most permissive.
- • Only the other permission bits.
2. Why can ls display a different owner name after an account-directory change even when the file was untouched?
Keep building