A reviewer approved a three-line addition to a store's rule set and a deploy identity gained read across a whole name branch — what did the review miss?
answer
- wording reviewed, effect not computed
- rules evaluate as a whole set
- the role hides its members
- a pattern matches wider than it reads
- approve the delta, recompute at apply
basics
~20 sThe review checked wording, not effect. Access rules are evaluated as a whole set, the subject named is usually a role whose members live elsewhere, and a name pattern matches more than it reads. Only a computed before-and-after tells you who gained what.
solid answer
~40 sA rule diff is text; access is the result of evaluating the *whole* set. Three things hide inside three lines. Rules compose — a new allow unions with what is already there, and whether anything overrides it depends on the store's precedence design. The subject is usually an indirection: the diff says `release-role`, not the forty identities in it, and that membership lives in another system entirely. And the object is a pattern, so how far a wildcard segment reaches is a property of the matcher, not of how wide the text looks. The reviewable artifact is therefore the **effect delta**: for each identity, which names and which rights before and after. Compute it from the proposed set, attach it to the change, and recompute it at apply time.
code
yaml · 4 lines# the reviewed change, in full: three lines
- grantedTo: release-role
names: "billing/*"
rights: [read, list]go deeper
Know that access is the result of evaluating all of a store's rules together, so a small addition can change what several identities hold.
Explain the three hiding places — how rules compose, a role whose members live elsewhere, and a name pattern that matches wider than it reads — and what a before-and-after effect view shows instead.
Make the preview binding: produced by the applier from the set it will apply, and recomputed at apply time against what was approved, with a refusal when it differs.
Decide what approvers are actually accountable for. If they approve wording, you have bought a signature; if they approve an effect, you have bought a control, and you now owe them a preview that is cheap and trustworthy.
## The text and the effect are different objects A change to a store's access rules is reviewed as a diff — added lines, removed lines. But nobody is ever granted a diff. What a caller holds is the result of evaluating the **whole rule set** against that caller and a name, at the moment of the call. The distance between those two things is where this failure lives, and it is invisible precisely because the diff looks small. Three lines is not a measure of anything. ## Three ways three lines become a large grant 1. **Composition.** Rules are a set, not a sequence of independent facts. A new allow unions with every allow already present, and whether a deny somewhere else narrows it back depends entirely on the precedence design — some stores let a deny beat any allow, others resolve by specificity, others by order. A reviewer who assumes the design they last worked with will read the same three lines and get a different answer. 2. **Indirection in the subject.** The rule names a role, a group or an owner. The diff shows that name. It does not show who is in it, and the membership usually lives in a different system under different ownership, changing on its own schedule. Granting a role a right is granting it to a population the diff never enumerates — and to everyone added to that population afterwards. 3. **Patterns in the object.** The rule names a branch of the name space with a wildcard in it. Whether that wildcard stops at a separator or crosses it, whether it matches the branch node itself as well as what is under it, and whether matching is case-sensitive are all matcher behaviour. The text reads narrow; the match set is what matters. ## What an effect preview is A preview evaluates **two** rule sets — the live one and the proposed one — over the identities and names that exist, and reports the difference per identity: - which names and rights each identity **gains**; - which it **loses**; - which rule in the proposed set produced each gain, so the reviewer can trace it back. That output is what an approver should be reading. The diff becomes supporting material, not the artifact. A gain of `read, list` over a whole branch of names is obvious on a preview and genuinely hard to see in the text that produced it. | Artifact | What it shows | What it hides | |---|---|---| | Text diff | The lines that changed | Composition, role membership, match reach | | Effect delta | Who holds which rights over which names, before and after | Names and members that do not exist yet | ## What a preview cannot tell you It is an evaluation over the world as it stands. It says nothing about a name created next month that the same pattern will match, and nothing about an identity added to that role next week. Both inherit the grant with no further review. That is why a preview at change time and a periodic recomputation of what everyone actually holds are two different controls, and the second one is its own subject. ## Making the preview binding The common half-measure is a preview produced by hand, pasted into the proposal, and never looked at again. Two rules make it real: - **The applier produces it**, from the same parsed set it will apply, so the preview and the apply cannot disagree about what the file says. - **The applier recomputes it at apply time and refuses if it differs from what was approved.** Between approval and apply, role membership changed, names were created, and another change may have landed. The approval covered an effect; if the effect is no longer that one, the approval does not cover it. ## How this gets found afterwards Almost always by someone asking a different question — an access review, a recomputation of who can reach a branch of names, an unexpected read. By then the grant has been live since the day it was approved, and the change looks perfectly proper in the history: it was proposed, reviewed and approved. That is the point of the failure. Nothing was bypassed. The wrong thing was reviewed.
- The preview was approved on Tuesday and the change applies on Friday — what must the applier check?It recomputes the effect from the current rule set, identities and names, and refuses to apply if the result differs from the effect that was approved. Membership changes, new names and other merged changes all move the answer between the two moments. Approval attaches to an effect, not to a file's wording.
- Why does naming a role rather than an identity make the review harder, not easier?The rule grants to a population the diff does not enumerate, held in another system with its own owners and its own change rate. Every future addition to that role inherits the grant with no rule change and therefore no review. The rule is reviewed once; the membership is not.
- Is an effect preview enough on its own?No. It evaluates the world as it stands at review time, so it cannot speak for names created later or members added later — both silently inherit. A preview bounds what a *change* does; keeping the standing picture honest over time is a separate, recurring review.
Reviewing the wording of an order to cut a new key, rather than walking the corridor and counting which doors the new key opens.
saying these in an interview costs you the question
- Says a short diff cannot widen access much
- Reads a rule's text as its effect
- Assumes the role named in the rule is small and stable
- Assumes a deny elsewhere automatically cancels a new allow
- Thinks a preview stays true after memberships change
- Accepts a preview pasted in by the change's author