Back to problem
Systems Administrator ICorePOSIX ACLs~35-45 min

The Permission Bits Look Right

ls says developer should have write access. developer still can't write. What is ls not telling you?

Your goal

Your goal is not just to make one write command succeed. Your goal is to learn that once a file has an extended ACL, the classic owner/group/other mode bits are no longer the whole policy — they're one layer of it. A named entry can request a permission and still be denied it, because a second layer, the ACL mask, acts as a ceiling above every named user, named group, and the owning-group entry. You'll learn to read a full getfacl listing end to end, tell a requested permission apart from an effective one, raise the mask deliberately instead of guessing, remove exactly the one entry that shouldn't exist, and re-check everything afterward — because even a routine chmod can quietly lower that ceiling again.

Diagnose
Detect
Read
Repair
Verify

developer needs to edit feature.flags and reports being blocked, even though an access rule for developer clearly asks for write. Meanwhile contractor — who should have lost access weeks ago — still gets in. Something is overriding the rules you can already see.

01

owner/group/other gives you exactly three buckets. Sometimes you need five.

The classic Linux permission model — owner, group, other, each with read/write/execute — covers most files just fine, but it has a hard limit:

  • It can only ever express three buckets of access at once
  • It has no way to say "this one specific extra person may also write here" without changing who the file's owner or group actually is
The real requirement — five different answers, one file
root (owner)          read + write
app (group)           read only
developer (a person)  read + write
auditor (a person)    read only
contractor (a person) no access at all

Traditional owner/group/other has one slot for "one specific person" — the owner — and it's already taken by root:

  • You could invent a new group for every exception
  • But that gets unwieldy fast
  • It's exactly the kind of awkward workaround that motivated a real extension to the permission model
owner / group / other
exactly three buckets — no room for one extra named exception
vs
ACL entries
named users and groups, layered on top of the classic three
EXPRESSIVE
Knowledge check 0

feature.flags needs: root rw, app group r, developer (a specific person) rw, auditor (a specific person) r, contractor no access.

Why doesn't the classic owner/group/other model express this directly?