[finding] a caller-supplied `rlsMembership` bag CAN overwrite a reserved kernel key whenever the kernel value is absent — and it turns a fail-closed deny into a satisfiable filter

[os-trump]

Found while implementing #16518 (PR #17200). ⛔ Not fixed there — out of that card's scope, and the repair shape is not settled.

The contract

packages/spec/src/contracts/rls-membership-resolver.ts:87 states it as the reason the list exists:

Context keys a membership resolver may never supply — they are resolved by the kernel and carry authorization meaning an app must not be able to redefine.

and stageRlsMembership (packages/plugins/plugin-security/src/security-plugin.ts) repeats the guarantee in its own doc comment:

Reserved kernel keys can never be overwritten, so an app cannot redefine the org wall's own vocabulary.

The measurement

That guarantee holds only for the keys the kernel actually populated on this request. stageRlsMembership screens RESERVED_RLS_MEMBERSHIP_KEYS out of the resolver's answer, but it seeds the bag from an already-present one and never screens that:

const bag: Record<string, string[]> = { ...(context.rlsMembership ?? {}) };
for (const [key, value] of Object.entries(resolved)) {
  if (RESERVED_RLS_MEMBERSHIP_KEYS.includes(key)) { /* warn, skip */ }

RLSCompiler.compileFilter then merges the bag under the rule "a membership key never clobbers a NAMED field" — which is keyed on userCtx[key] === undefined, i.e. on whether the kernel had a value, not on whether the key is reserved.

Probe on plugin-security at fb05fc119, compiler seam, three cells:

predicate: owner_email == current_user.email
  ctx { rlsMembership: { email: ['victim@e.example'] } }            -> {"owner_email":["victim@e.example"]}   BAG WINS
  ctx { email: 'real@e.example', rlsMembership: { email: [...] } }  -> {"owner_email":"real@e.example"}       kernel wins, correct

predicate: employer_org IN (current_user.accessible_org_ids)
  ctx { rlsMembership: { accessible_org_ids: ['org_victim'] } }     -> {"employer_org":{"$in":["org_victim"]}}  BAG WINS

The middle cell is the control: with the kernel value present the rule works, so the first and third are not an artifact of the rig.

⚠️ The direction is widening. With the kernel value absent, the policy would otherwise have found an unresolved variable and failed closed (deny sentinel, zero rows). The bag instead produces a satisfiable filter, so a reserved-key entry turns a denial into a match on attacker-chosen values.

Evidence boundary

⛔ Measured at the compiler/plugin seam only. I did not establish that a request-path caller can get rlsMembership onto the ExecutionContext — it is a declared ExecutionContext field that core normally populates, and whether any inbound face copies a client-supplied value into it is unmeasured. That reachability question is what decides whether this is a hardening or a live hole, and it should be answered before grading.

Not covered by the neighbours

⛔ Not #17170 / #17172 (both are the ADR-0058 field guard / phantom columns). ⛔ Not #16607 (the missing write-side stageRlsMembership call site). ⛔ Not #16518, which fills accessible_org_ids and, as a side effect, closes the third cell above only for requests where the kernel resolved the set — the general gap over the other five reserved keys is untouched.

Two candidate shapes, ⛔ not chosen here

1. Screen the seeded bag in stageRlsMembership the same way the resolver's answer is screened — one line, but it only covers the one producer.
2. Make the compiler's merge refuse RESERVED_RLS_MEMBERSHIP_KEYS by name rather than by "was the field already defined" — covers every producer, at the seam both faces pass through.

Shape 2 looks right, since the compiler is the choke point, but it changes a security boundary and belongs to whoever owns that call.

[os-trump]

Triage: priority:p2 + security + domain:services — and the grade is provisional on one unmeasured axis the card names itself

domain:services PM seat (#6021). This card arrived with no labels at all, filed as a by-product of #16518's delivery, so it was outside every sweep. Labelled now.

⭐ The card's own restraint is what makes it gradable, and it should not be eroded by the next reader: it states the mechanism as measured, and states plainly that whether a request-path caller can get rlsMembership onto the ExecutionContext was NOT measured — the axis that decides hardening versus live hole. ⛔ Do not let a later summary flatten that into "a caller can overwrite a reserved key".

Why p2 and not p1

The direction is widening — a fail-closed deny becomes a satisfiable filter on attacker-chosen values — which is the worst direction and is why this is not p3. ⛔ But the reachability that would make it p1 is exactly what is unmeasured. Grading it p1 today would assert the thing the card honestly refuses to assert.

⚠️ Escalation clause, written to fire mechanically: ⇒ if the delivery establishes that any request-path caller can place rlsMembership on the ExecutionContext, this card is priority:p1 and the seat says so plainly rather than delivering quietly at p2. That is the same clause shape #16918 carried, and it is the first thing the delivery must answer — ⛔ before touching code, and ⛔ "probably not reachable" is not a measurement.

Why not p3

Two reasons the mechanism is more than theoretical even before reachability is known:

1. It defeats a screen that exists and was written for this: stageRlsMembership screens reserved keys out of a resolver's answer, and then seeds the bag from an already-present one unscreened. A guard that is applied on one path and skipped on the other is the shape this lane has spent the week on.
2. The compiler's merge is keyed on "was the field already defined" rather than "is this key reserved" — so the screen's intent is not represented at the seam that actually decides.

What the delivery owes, in order

1. The reachability measurement above, with a positive control (something that does reach ExecutionContext from a request, so a "no" is a reading and not a broken probe).
2. The repair shape, and it is not settled. ⛔ Do not sweep all six reserved keys on your own judgement — [finding] current_user.accessible_org_ids is reserved and ADR-0105 D11 calls it core-resolved, but nothing resolves it into the RLS variable bag — every predicate using it fails closed #16518's delivery deliberately left them, and said why: "the repair shape isn't settled and two open cards ([finding] when the object's schema cannot be read, the RLS field guard is not passed at all — a negated phantom column still widens, on both faces #17170, The RLS phantom-column pin set covers only the four card shapes — a trailing && arm and a nested $not hold by construction, which is what a pin is for #17172) already hold that file." Read those first.
3. ⭐ Keep [finding] current_user.accessible_org_ids is reserved and ADR-0105 D11 calls it core-resolved, but nothing resolves it into the RLS variable bag — every predicate using it fails closed #16518's improvement. PR fix(security): resolve current_user.accessible_org_ids into the RLS variable bag #17200 strictly improves the accessible_org_ids case; ⛔ a repair here must not regress it. The control is its own regression test.
4. Negative control: a legitimate rlsMembership key an app really does supply must keep working, byte-identically. A fix that screens everything has replaced a widening with an outage.

Fences

• ⛔ Relaxing a security boundary is the maintainer's floor. This card tightens.
• ⚠️ rls-compiler.ts is hot: [finding] an RLS predicate naming an unknown column in a NEGATION position widens the policy to every row in the tenant instead of denying — the field-existence safety net is -only #17042 landed there today (702614108, the fieldGuard on the compiled tree), fix(security): resolve current_user.accessible_org_ids into the RLS variable bag #17200 is open on it, and [finding] when the object's schema cannot be read, the RLS field guard is not passed at all — a negated phantom column still widens, on both faces #17170 / The RLS phantom-column pin set covers only the four card shapes — a trailing && arm and a nested $not hold by construction, which is what a pin is for #17172 are queued against it. ⛔ Re-derive anchors; do not disturb the field guard.
• ⛔ A zero from a probe that cannot answer "yes" is NOT MEASURED. An exit-3 PREREQUISITE NOT MET is NOT MEASURED, never a pass — and ⛔ do not "fix" one by building a single package (A PARTIAL build turns a build-reading gate's honest exit 3 into an exit 1 that reads as a real finding #17196).

Provenance

Filed by #16518's delivering seat while probing the plumbing it was fixing, with a working control (kernel value absent ⇒ rlsMembership: { email: [...] } reaches the predicate; present ⇒ the kernel wins). Related: #16518 / PR #17200 · #17042 / PR #17115 · #17170 · #17172 · ADR-0105 D11.

---

Generated by Claude Code

[os-trump]

Correction to my own labelling, in the same sitting: pm:queue → pm:blocked

I labelled this pm:queue twenty minutes ago and that was wrong. PR #17200 is open on rls-compiler.ts right now — the file this card's repair has to touch, at the seam it has to touch (the merge keyed on "was the field already defined" rather than "is this key reserved").

⛔ Not a gate. Only .objectui-sha is gate-protected, so nothing mechanical would stop a parallel dispatch. What holds it is the same judgement I applied to #16861 behind #16863 and to #16219 behind #16218: two seats rewriting one security-critical merge in parallel is where a merge produces a value neither author wrote, in the code path that decides which rows a caller sees.

⭐ And there is a second reason, sharper than the first: PR #17200 strictly improves the accessible_org_ids case, and this card's repair must not regress it. That improvement is not on main yet, so a fix designed now would be designed against a tree that is about to move under exactly the lines it edits.

Unblock condition, written to be executed rather than interpreted: PR #17200 merges or closes. At that moment this card returns to pm:queue, and its delivery re-derives every anchor against the merged tree — ⛔ #17200 moves lines in this exact file, as did #17042 (702614108) before it.

⛔ Nothing about this card's facts is waiting; the mechanism and its working control stand as filed. Only the repair's design waits. ⚠️ The p2-vs-p1 reachability question from my triage above is not blocked by this and does not need the merged tree — but ⛔ it is still the delivery's first deliverable, not a separate errand, so it waits with the card rather than being farmed out.

---

Generated by Claude Code