In this chapter
We'll open up real file permissions — owner, group, and other, each independently readable, writable, and executable — stored right in the inode, and see exactly why GreenMart's backup process could read the invoice file without owning it.
The Problem in Real Life
Mike looks at the invoice file's real permission bits Sarah pulled up: rw-r-----. "I can barely read this," he admits. "But I do want to know — how did the backup process even get to open a file it doesn't technically own?"
Sarah points at the group field. "Because ownership and permissions aren't one single yes-or-no switch. They're three real, separate audiences."
'rw-r-----' — what am I even looking at?
Mike
One Lock vs. Three Real Audiences
Three real audiences, not one
Owner, group, and other each get independent read/write/execute permissions — nine real yes/no answers per file.
Permissions live on the inode
Because permission bits sit in the inode, not a directory entry, every name pointing at the same inode shares identical access.
Permissions & Ownership
Every file's real permissions, stored right in its inode (the chapter before last), answer a genuinely more specific question than "can this be opened or not." They answer it separately for three distinct real audiences: the file's owner, its assigned group, and everyone else.
- Owner, group, and other — three real audiences, not one. A file has exactly one owning user and one assigned group, both stored in its inode. Permissions are set separately for each of these three: what the owner can do, what any member of the assigned group can do, and what every other user on the system can do. GreenMart's own backup process reading the invoice, despite not being the file's literal owner, is possible precisely because it belongs to the file's assigned group — real, deliberate group-based access, not an accident.
- Read, write, execute — three real actions, per audience. For each of those three audiences, three separate bits genuinely control: read (can the content be viewed), write (can the content be changed), and execute (can this file be run as a program, or — for a directory specifically — can its contents even be listed at all).
rw-r-----reads as: owner can read and write; group can only read; other can do nothing at all. - Why this genuinely matters for a directory, not just a file. A directory's own execute bit has a real, distinct meaning: without it, a user can't even look inside — can't list what names exist, can't resolve any path that walks through it, regardless of what permissions the files inside might otherwise have. This is a real, common source of confusing "permission denied" errors: the file itself might be perfectly readable, but a directory somewhere along its path isn't.
- Permissions live on the inode, not on any one name. Because permission bits are stored in the inode (not in a directory entry), every real name pointing at that same inode — as the very next chapter, Hard Links, makes concrete — shares the exact same permissions. There's no such thing as one hard link to a file being "more open" than another; they're the same inode, so they're the same real permissions, full stop.
| Audience | Read | Write | Execute |
|---|---|---|---|
| Owner | yes | yes | no |
| Group | yes | no | no |
| Other | no | no | no |
Nine real yes/no answers, not one — this is exactly how the backup process (in the file's assigned group) can read the invoice without owning it, and how a random other user genuinely cannot.
GreenMart's real invoice mystery just gained one more confirmed, real fact: the backup process's access wasn't a bug or an accident — group permissions were deliberately set up to allow it, exactly as this chapter's own framework predicts.
Key Takeaway
A file's permissions aren't a single lock — they're nine real, independent yes/no answers across three audiences (owner, group, other) and three actions (read, write, execute), stored on the inode itself, which is why every name pointing at the same inode always shares the exact same access.
Why This Matters
Every real access-control decision GreenMart makes on its servers — which processes can read customer data, which scripts can modify configuration, which backup jobs can reach which files — is built from exactly this owner/group/other, read/write/execute framework, underneath whatever higher-level tooling sits on top of it.
GreenMart now understands real file permissions as nine separate answers across three audiences, stored on the inode and shared by every name that points at it. The next chapter goes deep on exactly what it means for more than one name to point at that same inode: hard links.