checkAuthoredRowWrite abstains on every `private`-OWD cross-owner row, so #5493's by-id widener deferral is inert on the posture it was filed for — and its unit test cannot see it (fake engine bypasses middleware)

[os-zhuang]

Measured while running the #6736 bulk-path probe (PR #7274). Filed unassigned, out of that PR's scope, for triage.

What was measured

ISecurityService.checkAuthoredRowWrite resolves its verdict by re-reading the target row through the caller's own execution context:

const parts = [{ id: recordId }, ...(layer0 ? [layer0] : []), layer1];
const row = await this.ql.findOne(object, { where: { $and: parts }, context });
return row ? 'admit' : 'abstain';

packages/plugins/plugin-security/src/security-plugin.ts, in checkAuthoredRowWrite.

That findOne re-enters the middleware chain, so plugin-sharing's read filter applies. buildReadFilter scopes a private-OWD object to owner-match OR shares — so a cross-owner row is invisible to the caller, findOne returns null, and the verdict is abstain rather than admit. The middleware's refusal then stands and the write is refused 403, even though the app declared a widener that admits the row by name.

Measured end-to-end on the real stack (bootStack + real SecurityPlugin + real SharingServicePlugin + real ObjectQL engine). Two objects, identical in every respect except the OWD, same app-authored widener (operation: 'update', using: "stage == 'open'"), same principal, same cross-owner row shape:

object	OWD	checkAuthoredRowWrite on the cross-owner admitted row	by-id PATCH
probe_note	public_read	admit	200, row changes
probe_secret	private	abstain	403, row unchanged

Control ruling out an inert or mis-parsed widener: on the same private object, checkAuthoredRowWrite for the caller's own open row answers admit. The declaration is live there; it is the cross-owner read that removes it.

Why this matters

private is the posture the widener surface was built for. #5493's own measured defect is described as occurring exactly where record sharing enforces — "a private/public_read OWD and an owner_id field" — and the sharing middleware's deferral comment says the probe exists so that gate does not refuse a row an app-authored widener admits. On private, it still refuses: the deferral is asked, and structurally cannot answer admit for any row the caller cannot already read.

So the shipped by-id half functions on read-open objects and stands down on read-closed ones — discriminated by a property the widener's author never mentions, which is the same shape #5493 was filed about one layer up.

The second half: the unit test cannot see this

packages/plugins/plugin-security/src/row-write-widener-composition.test.ts asserts

await expect(
  stack.security.checkAuthoredRowWrite('crm_opportunity', OPP_THEIRS.id, 'update', WIDENED_CTX),
).resolves.toBe('admit');

on crm_opportunity, which is declared sharingModel: 'private' — the posture that answers abstain in production. It passes because that file's makeEngine() fake implements find as a direct row filter with no middleware chain, so the re-read inside checkAuthoredRowWrite is never scoped by the sharing read filter. The double is looser than the producer on precisely the axis the method's verdict depends on, so the test is green over behaviour the real stack does not have.

This half is actionable regardless of how the first half is ruled: if the abstention is intended (fail-closed, "you may not write what you cannot read"), the unit test is asserting the opposite of the contract and should be inverted plus the intent written into the method's doc; if it is not intended, the test is why it shipped unnoticed.

Two readings, offered honestly

I measured behaviour, not intent, and both readings are defensible:

1. Intended fail-closed. Resolving the verdict under the caller's own scope is a deliberate refusal to let a write reach rows the caller cannot see. Then the gap is documentation plus the misleading test — and app authors need to be told that an update-widener on a private object requires matching read widening (viewAllRecords, a read policy, or a share) to do anything.
2. Unintended. The verdict is meant to answer "does the declaration admit this row", which is a question about the row and the policy, not about the caller's read scope; re-reading under the caller's context silently folds a read decision into a write decision. Then the read should be resolved under a scope that can actually see the row while the write decision stays with the pre-image gate.

Deliberately not choosing here — the difference is a contract question about what checkAuthoredRowWrite means, which belongs to the maintainer, not to the agent that tripped over it.

Repro

The measurement was taken with a throwaway variant of the probe added in PR #7274 (a second object identical except sharingModel: 'private', plus a case logging both verdicts and both HTTP statuses). It was deliberately not committed — that PR is scoped to the bulk path. The committed harness in packages/qa/dogfood/test/bulk-widener-probe.dogfood.test.ts is two dozen lines away from re-taking it.

[os-zhuang]

Provenance footer for this filing (the issue body loses it — two issue_write attempts stored the body with the trailing rule and footer removed, while the same block survived intact on PR #7274's body, so the strip is specific to issue bodies here and is not an omission by the filer).

---

Generated by Claude Code

[os-zhuang]

Triage: needs-user-decision + domain:identity.

• Class: the card is an explicit contract question, measured honestly from both sides — checkAuthoredRowWrite resolves its verdict through the caller's own read scope, so on a private-OWD object the by-id widener deferral structurally cannot answer admit for any cross-owner row, which is the posture On objects that carry sharing rules, sharing middleware answers FORBIDDEN before RLS update-wideners are consulted — the identical widener works on rule-less objects #5493's widener surface was built for. Reading 1 (intended fail-closed: "you may not write what you cannot read") and reading 2 (unintended: a read decision silently folded into a write decision) lead to opposite remedies, and the filer correctly declined to choose. That is a public-contract ruling — what checkAuthoredRowWrite means — so it goes to the decision box, not the queue.
• Decision-light half, flagged for whichever way the ruling goes: the unit test (row-write-widener-composition.test.ts, checkAuthoredRowWrite(...).resolves.toBe('admit') on a private-declared object, verified live at :521 on origin/main @ 397e731) asserts behavior the real stack does not have, because its fake engine bypasses the middleware chain. Either ruling makes that test wrong as written — invert it + document intent (reading 1) or fix the resolution scope (reading 2).
• Routing anchor: packages/plugins/plugin-security/src/security-plugin.ts — checkAuthoredRowWrite verified at :749/:754; fix lands in plugin-security under either reading ⇒ domain:identity.
• Dedup: distinct from Authored RLS update-wideners are silently ineffective on the bulk write path — buildWriteFilter ANDs them away (fewer rows, no error) #6736 (bulk-path wideners, pm:on-hold) — this was found running Authored RLS update-wideners are silently ineffective on the bulk write path — buildWriteFilter ANDs them away (fewer rows, no error) #6736's probe (PR test(dogfood): probe app-authored RLS wideners on the bulk write path (#6736) #7274) and filed out of that PR's scope; the filer's provenance comment covers the footer strip. No other open card names checkAuthoredRowWrite.
• target:v17: not applied — fails-closed direction (403 where an app author expected admit), no data corruption or silent widening; a refusal defect on an app-authoring surface, not a shipped-face user hit today.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-10, directed in session session_01BPWqbmEFU8gJepBJTHESXd): reading 2 — the deferral answers the declaration, not the caller's read scope.

checkAuthoredRowWrite's question is "does the declared widener admit this row"; resolve the probe read under a scope that can see the row (system/elevated), while the write decision stays with the pre-image gate. Otherwise the by-id widener is structurally dead on private — the posture #5493 built it for. No leak either way: the final write gate still enforces.

Independently and first: fix the unit test half — row-write-widener-composition.test.ts's fake engine bypasses the middleware chain and asserts behavior the real stack does not have. The probe harness in bulk-widener-probe.dogfood.test.ts is the template for a real-stack pin.

needs-user-decision → pm:queue.

---

Generated by Claude Code