[finding] The bulk AST write path passes `opCtx.operation` raw, so `purge` / `transfer` / `restore` derive no row scope while `update` / `delete` now do (#7665 asymmetry)

[os-help]

Found by the PM while reviewing PR #7792 (#7665). Not a regression — the behaviour described here is the same before and after that PR — but #7665 creates an asymmetry between the two write paths that deserves a deliberate answer rather than an accident.

What #7665 changed, and where it stops

#7665 makes an empty write-class policy collection derive its row scope from the caller's select narrowing, inside computeLayeredRlsFilter. The derivation is written for operation === 'update' || operation === 'delete'.

On the by-id write pre-image gate (step 2.7) that is complete coverage, because the gate normalises first (security-plugin.ts:1487-1489):

const rlsOperation =
  opCtx.operation === 'purge' ? 'delete'
  : opCtx.operation === 'transfer' || opCtx.operation === 'restore' ? 'update'
  : opCtx.operation;

so all six write verbs reach the derivation as update or delete.

On the bulk AST injection path (step 3) there is no such normalisation — opCtx.operation is passed raw:

• security-plugin.ts:2113 — computeRlsFilter(permissionSets, opCtx.object, opCtx.operation, opCtx.context)
• security-plugin.ts:2133 — the ADR-0090 D10 delegator half, same shape

A bulk write arriving as purge, transfer or restore therefore collects no policies for that literal operation name, derives nothing, and has no row scope AND-ed into its AST — while a bulk update or delete on the same select-only object now does.

Why it is worth answering rather than assuming

Two questions, and they have different answers:

1. Can those verbs reach the AST path at all? If opCtx.ast is only ever populated for find / update / delete, the asymmetry is theoretical and the right fix is a comment saying so. That is a reading job on the engine's dispatch, not a guess.
2. If they can, then a select-only object has bulk purge / transfer / restore unscoped by row visibility while by-id and bulk update / delete are scoped — the same class of defect [security] A by-id write is not gated by record visibility — a contributor mutates records they cannot read, when only select-scope RLS is authored #7665 fixed, on the verbs whose blast radius is largest (purge destroys; transfer reassigns ownership).

Note the two paths already normalise differently for a reason that may be legitimate — the 2.7 gate is asking "may this caller write THIS row", the AST path is scoping a set — so the fix may be "normalise there too" or may be "these verbs never take the AST path, and here is the assertion that says so".

Related, deliberately not merged into this

• [security][立项位] M2 权限生命周期(undelete/purge)功能与 allowRestore/allowPurge RBAC 同批建设(evaluator 已 fail-closed,allowTransfer 已 enforced) #1883 (pm:on-hold) covers allowRestore / allowPurge RBAC — the object-level bit, a different layer from row scope. If that card is ever taken up, this finding belongs in the same sweep.
• The by-id write pre-image gate resolves the row under the caller's own read scope, so an app-authored widener is still dead on private even once checkAuthoredRowWrite admits it #7401 / Authored RLS update-wideners are silently ineffective on the bulk write path — buildWriteFilter ANDs them away (fewer rows, no error) #6736 track the opposite direction (authored write wideners going dead). Any fix here must not derive when a write-class policy applies, exactly as [security] A by-id write is not gated by record visibility — a contributor mutates records they cannot read, when only select-scope RLS is authored #7665 does not.

Provenance

PM review of PR #7792, verified against origin/main at the time of writing (:1487-1489 normalisation present; :2113 / :2133 raw). Filed unassigned and unqueued — recording, not claiming. Sizing note for whoever takes it: the @objectstack/verify harness gap (#7762) does not apply here, but the coverage would need a bulk-write fixture on a select-only object, which the #7665 suite (select-only-write-visibility.test.ts) already has the personas for.

[hotlong]

Findings-round promotion: pm:queue (domain:identity kept, security kept, type Bug) — first grading.

The forecast became a fact: #7665 closed 2026-08-11 via merged PR #7792, and its fix did not extend to the AST path. Verified on origin/main: the 2.7 gate normalisation (purge→delete, transfer/restore→update) is live at security-plugin.ts:1542-1544, while the bulk AST path (:2172) and the ADR-0090 D10 delegator half (:2192) both still pass opCtx.operation raw. (Line anchors drifted from the card body; locate by symbol.)

Dispatch note: reachability (whether opCtx.ast is ever populated for purge/transfer/restore) is unresolved by static reads — it is the fix's first task. Both honest outcomes are acceptable deliverables: normalise those two sites, or prove the verbs never take the AST path and pin that with an assertion. Existing persona fixture: select-only-write-visibility.test.ts.

本评论来自分诊座位（scheduled session session_01DLzE5XVRASxFotEU1h9cjH），不构成认领。

---

Generated by Claude Code