A `controlled_by_parent` detail's own ownership floor is never droppable, so a cross-creator by-id UPDATE of a child is refused before the master gate — Modify All Data included

[qq9340100]

Found while implementing #8679 (PR #8758). Not fixed there — it is a different gate with a different guard, so it is recorded rather than ridden along. #8679's acceptance cases deliberately hold the detail's floor constant so that card's verdicts stay attributable to the master gate alone.

What was measured

On an ADR-0055 controlled_by_parent detail, a by-id UPDATE of a child row created by another user is refused at the by-id write pre-image gate (step 2.7) — before assertControlledByParentWrite runs at all — regardless of whether the caller may edit the master. The refusal is record_access_denied ("You do not have access to this record…"), not the master-editability sentence.

The mechanism, and why no widening mechanism can reach it:

1. The platform ownership floor owner_only_writes is declared object '*', so it applies to the detail like any other object.
2. Step 2.7 drops the floor only when resolveSharingWriteVerdict(...) === 'allow'.
3. That verdict comes from SharingService.checkEdit, which returns abstain for any object whose effectiveSharingModel is public — and controlled_by_parent maps to public there.
4. The public early return sits above the modifyAllRecords branch (hasModifyAllBypass is asked last, at step 3), so the bypass is never consulted for such an object.

Net: on a controlled_by_parent detail the floor is unconditional and unwidenable — not by ownership depth, not by an edit-level sys_record_share, not by Modify All Data.

Reproduction (unit, in-memory, no server)

Fixture: master crm_campaign (private, owner_id), detail crm_campaign_member (controlled_by_parent), a detail row created_by ADMIN under a campaign owned by MKT, and the shipped member_default seed for the floor. Driving the real SecurityPlugin middleware plus the real sharing middleware:

update marketing mem_mkt_byadmin -> refused: "You do not have access to this record…"
update admin_set mem_mkt -> refused: "You do not have access to this record…"
update admin_set mem_admin_selfmade -> refused: "You do not have access to this record…"

The middle line is the sharp one: admin_set carries viewAllRecords: true, modifyAllRecords: true on both objects and is still refused on a detail row it did not personally create, under a master it can fully edit.

Why it looks wrong

controlled_by_parent means "access is derived from the master". The detail declares nothing about who may write it — platform-ownership-policies.ts says exactly that, as the reason the public_read_write floor exemption must NOT be extended to controlled_by_parent:

controlled_by_parent derives its access from the MASTER record, which has its own OWD and its own gate (assertControlledByParentWrite) — the detail declares nothing about who may write it

That reasoning justifies not treating the detail as org-wide-open. But the current behaviour goes further than "not open": it makes the detail creator-only, which is a row-level write rule the detail also never declared, and one the master gate cannot override. Two gates now answer the same write, and the stricter one is the one derived from nothing the author wrote.

Note the asymmetry that makes this easy to miss: an INSERT does not go through the pre-image gate at all, so creating a child under an editable master works; only later by-id updates of someone else's child are refused. The read path is unaffected.

Prior art, and why this is not a duplicate

• modifyAllRecords still does not widen a by-id write on an object with NO owner field (sharing abstains, the platform created_by floor holds) #6698 (closed) — "modifyAllRecords still does not widen a by-id write on an object with NO owner field (sharing abstains, the platform created_by floor holds)". Same mechanism, different trigger: there the abstain came from a missing owner field, here from the controlled_by_parent posture. The public-model early return is a separate route into the same dead end.
• A public_read_write object is only writable by the row's creator — showcase_contributor gets 403 editing a showcase_project it can read, where the access matrix declares edit:true #8023 (closed) — added the OWD floor exemption for public_read_write and explicitly declined to extend it to controlled_by_parent. That decision is the reason this case exists; whether it should be revisited for details specifically is the question here.

Possible directions (not a recommendation — this needs triage)

1. Let the master gate be authoritative for details: skip the platform ownership floor at step 2.7 for controlled_by_parent objects, on the grounds that assertControlledByParentWrite is that object's declared row-level write gate and already runs on the same operation.
2. Reorder checkEdit so the modifyAllRecords bypass is consulted before the public-model early return — narrower, and fixes only the superuser arm, leaving ordinary cross-creator writes refused.
3. Accept it as intended and document that controlled_by_parent details are creator-only for by-id updates — in which case A public_read_write object is only writable by the row's creator — showcase_contributor gets 403 editing a showcase_project it can read, where the access matrix declares edit:true #8023's comment should say so, because today it reads as though the master gate governs.

Option 1 changes a permission boundary and should not be taken without a maintainer ruling.

---

Filed unassigned and unlabeled for triage. Related: #8679, PR #8758.

Generated by Claude Code

[hotlong]

Triage: lands in packages/plugins/plugin-security (step 2.7 by-id write pre-image gate) and plugin-sharing's SharingService.checkEdit ⇒ domain:identity. Type Bug. Escalated to the maintainer — NOT auto-adjudicated.

Routed from the landing package, not from the title: every one of the three directions edits the security/sharing gate pair, not the metadata or spec layer.

Why this is the maintainer floor rather than the auto-adjudication lane

The mechanical boundary test decides it. No remedy here is accept-set-neutral: direction 1 drops a platform ownership floor for a whole OWD class, and direction 2 reorders a modifyAllRecords bypass ahead of a model early-return — both widen who may write rows that are refused today. That is a permission-boundary change, which the skill's manual floor names explicitly ("放宽访问控制 … 是伪装的产品决定"). Direction 3 (accept as intended, document it) is equally a ruling about what controlled_by_parent means. Nothing here is a restoration of declared = enforced, so it does not qualify for the 代裁 lane.

The card is typed Bug on a narrower ground than the remedies: controlled_by_parent is documented as deriving access from the master, and the measured behaviour adds an undeclared creator-only write rule the master gate cannot override. What to do about that is still the maintainer's.

⚠️ Sibling card in the same gate — worth ruling together

#7401 is the same pre-image gate (step 2.7) refusing a write the composed filter already admits, reached through a different door: there the row is invisible to the gate's caller-scoped probe read on a private OWD; here the ownership floor is undroppable because checkEdit abstains on the public-mapped controlled_by_parent model. #7401 states the general question in one line — "May a caller write a row they cannot read / whose floor no mechanism can drop, when a declaration admits it by predicate?" — and has been on hold since 2026-08-10 awaiting exactly this ruling. Two cards, one gate, one question in two postures. #7401 has been given domain:identity this round so it stops being invisible to the lane.

Prior art the card correctly identified and is not a duplicate of: #6698 (same dead end via a missing owner field), #8023 (the ruling that declined to extend the OWD floor exemption to controlled_by_parent, which is why this case exists).

Four-facet card face

• Platform long-term coherence — today two gates answer one write and the stricter one is derived from nothing the author declared; A public_read_write object is only writable by the row's creator — showcase_contributor gets 403 editing a showcase_project it can read, where the access matrix declares edit:true #8023's comment reads as though the master gate governs, which measurement shows it does not. Direction 1 collapses that to one declared gate per write and shrinks the special-case count; direction 2 leaves the two-gate structure standing and fixes only the superuser arm; direction 3 keeps the structure and pays for it in documentation that must now say details are creator-only.
• Measured business pull — measured in a unit repro, not from a deployment. The sharp case (admin_set carrying modifyAllRecords: true on both objects, still refused on a child it did not create, under a master it may fully edit) is the shape an operator would report as a Modify All Data bug. INSERT is unaffected and the read path is unaffected, so the blast radius is by-id updates of another user's child rows on controlled_by_parent details.
• AI-agent error-resistance — an app author declaring a master-detail pair gets a write rule they never wrote and cannot discover from their own metadata; the refusal sentence (record_access_denied) names neither the master gate nor the floor. Whatever is ruled, the diagnostic should name the gate that refused — that half is error-resistance regardless of direction.
• Startup scope discipline — direction 3 costs one comment edit and is honest but leaves the platform teaching a rule nobody declared. Direction 2 is the narrowest code change but leaves ordinary cross-creator writes refused, i.e. it buys the superuser case only. Direction 1 is the widest and the only one that closes the class.

PM recommendation, offered not chosen: direction 1, conditioned on the pre-image gate still running its own read for the master (the derivation must actually be exercised, not skipped) — with direction 2 rejected as a half-measure that fixes the case an operator notices while leaving the case an app author hits. ⛔ Do not dispatch until ruled; the queue label stays off deliberately.

---

Generated by Claude Code