The Access-Control Incident
Three unrelated access bugs, one incident. Which mechanism actually governs each one?
Your goal is not to run a handful of ACL and sudo commands until the complaints stop. Your goal is to treat access administration as policy implementation: write the allow/deny matrix first, so you know exactly what "fixed" means before you touch anything. Then, for every cell in that matrix, identify which distinct Linux mechanism actually governs it — identity and group membership, directory traversal, file mode bits, access ACLs, default ACLs, or sudo rules — because a fix aimed at the wrong layer does nothing. Repair current objects and future ones, since a policy that only survives until the next file is created isn't a policy. Finally, test every cell in the matrix as the real subject, not as root, because root bypasses the very checks you're trying to prove are correct.
Payroll exports on this server have drifted from policy in three independent ways at once: a contractor who should have lost access still has it, finance can't read what they're supposed to, and support can run any command as root instead of just restarting one service.
Before you touch the server, write the policy down
It's tempting to read an incident report and start typing commands the moment you spot something wrong. Resist that:
- The report describes a mix of people, a shared resource, and expected outcomes
- Until you turn that prose into an explicit access matrix, you have no way to know when you're actually done
An access matrix is just a table:
- For every subject (a user or role)
- Which resource they touch
- Which actions they should be allowed to take
- And which they should be explicitly denied
- The source discipline here is formal: subject × resource × allowed action
# payroll-job -> /srv/payroll/exports -> write
# finance -> /srv/payroll/exports -> read
# contractor -> /srv/payroll/exports -> deny
# support -> payroll-exporter service -> status/restart onlyNotice that this matrix has both allow rows and deny rows:
- A denial that isn't written down is a denial nobody will remember to test
- An incident like this one is defined as much by what should be refused as by what should be permitted
It's easy to declare victory the moment the allowed actions work — payroll-job can write, finance can read, ship it. But a positive result proves nothing about the denials sitting right next to it in the matrix. If contractor can still read the file, the incident isn't half-fixed, it's unfixed — you just haven't tested the row that would tell you.
The incident report is three paragraphs of prose about payroll-job, finance, contractor, and support.
What's the right first move, before running any command on the server?