删除记录时「引用清理」的写入半边仍以操作人身份执行:引用表非空时删除依然 403(#12166 裁决刻意划定的边界,报一次让维护者知情)

[os-warren]

一句话

#12166 的裁决（2026-08-26，选项 A）把删除前的引用检查切成了系统身份，约束 1 明确限定「删除路径的其他任何部分身份不变」。因此引用清理的写入半边 —— set_null 的 UPDATE 与 cascade 的子记录 DELETE —— 仍以操作人身份执行。结果：原报告里那批「有删除权、对引用表无任何权限」的角色，只有在引用表为空时删除才通得过；引用表真的有引用行时，依然 403，只是报错从 find 变成了 update。

这不是 #12166 的实现缺陷，也不是要推翻裁决 —— 它正是约束 1 划定的边界。开这张卡只是因为该边界的实际影响没有被测量过，而它决定了原报告那 17 组「角色×对象」里到底有多少被真正修好。

证据（PR #12596 里已 pin 成断言）

packages/plugins/plugin-security/src/delete-reference-cleanup-system-identity.test.ts：

it('the elevation is the CHECK only — a non-empty referencing table still needs
    the caller\'s own write authority (constraint 1)', ...)

  expect(err.code).toBe('PERMISSION_DENIED');
  expect(err.details?.object).toBe('os_ehr_andon_record');
  expect(err.details?.operation).toBe('update');   // ← 不再是 'find'

夹具与原报告同形：对象 A 被 B 的可空 lookup 引用（解析行为 = set_null），角色对 A 有完整删除权、对 B 无任何授权。B 为空 ⇒ 删除成功（#12166 修好的部分）；B 有一行 ⇒ 仍然 403。

为什么值得单独判一次

• 原报告的 17 组配置里，引用表非空的那些仍然按不动删除按钮，症状与修复前对用户完全一致（同样是一句通用「您没有执行此操作的权限」）；从部署方视角看，问题只解决了一部分，而这一点在 删除记录时「引用清理」用操作人身份查询引用表,读权不足即整体 403(应以系统身份执行) #12166 的验收里看不出来。
• 裁决为引用检查给出的论证 —— 引用完整性动作是引擎责任、主流平台一律以系统身份执行（RDBMS FK 的 SET NULL／CASCADE、Salesforce 的 lookup 清空与级联删除均记载为绕过 sharing）—— 在文义上同样覆盖写入半边：FK 基线里真正以引擎身份执行的正是那个 SET NULL／DELETE。裁决把范围钉在查询上是刻意的（卡片正文与决策分析通篇只说「查询」），但据我所读，那个范围收窄没有单独论证过写入半边应当保留操作人身份 —— 它更像是照着 issue 的措辞划的，而不是对写入半边下的判断。
• 反方向也确实存在：cascade 的子删除以系统身份执行意味着「有 A 的删除权 ⇒ 可以删掉自己无权删除的 B 行」，这是一个远比读权外溢更大的权限语义变更，绝不该顺手带过。set_null（只清 FK 列）与 cascade（删整行）在这个维度上不对称，很可能需要分别裁。

建议处置

维护者判一次，三个方向：

• A. 维持现状（裁决的字面范围）：写入半边保持操作人身份。代价：原报告的部署仍需为每个可删角色补齐引用表的写权限，「删除权 = 删除权 + 引用表权限」的隐藏耦合只是从读权变成了写权，在权限界面上同样不可见。
• B. set_null 也切系统身份，cascade 不切：清空 FK 列是纯粹的完整性维护（且已有 属主守卫与级联 set_null 冲突:非特权删除 sys_user 时 owner_id 级联置空被 #3004 守卫拦截(级联中途失败) #3023 的 __referentialFieldClear 标记把它标为引擎内部写入），而删掉整行是数据销毁，保留操作人授权。这一档最贴近 FK 基线。
• C. 两者都切：完全对齐 Salesforce/Dataverse 的级联语义。权限面变更最大，需要独立论证。

⚠️ 无论哪个方向都是权限边界语义变更，条款②适用，应走 needs-user-decision 而不是直接派发。

出处

• 裁决：删除记录时「引用清理」用操作人身份查询引用表,读权不足即整体 403(应以系统身份执行) #12166 的 2026-08-26 评论（选项 A + 四条约束）
• 实现与 pin：PR fix(objectql,spec): run the pre-delete reference check under the system identity #12596
• 原始部署实测记录：steedos-labs/os-project-titanwind-ehr#1809

---

Generated by Claude Code

[os-support-ai]

Triage (triage seat, session session_01G28JXov51zX81Ky6M4r25m): decision box — needs-user-decision + domain:engine (family precedent: the ruling card this follows up, same delete-path surface), type Feature (options B/C expand the accepted set of the delete operation — the mechanical boundary test). This is a security/permission-boundary question and it would extend the scope of a maintainer ruling made today, so it sits on the human floor twice over — auto-adjudication does not apply, and the card's own framing agrees (条款② applies to any outcome). Not dispatchable; enters the maintainer's decision inbox.

Decision-box filing follows (中文,按裁定格式):

<!-- os-decision-facets -->

一句话问题:上一裁已让删除前的「引用检查」以系统身份执行,但「引用清理」的写入仍用操作人身份——所以只要引用表里真的有引用行、而操作人对那张表没有写权限,删除照样被拒;拿到删除权的角色在权限界面上看不出还差什么。

选项 × 真实代价:

• A(维持裁决字面边界,写入半边保持操作人身份):零改动。代价:部署方须为每个可删角色补齐所有引用表的写权限;「删除权 ≠ 真能删」的隐藏耦合从读权换成写权,界面上依旧不可见;原始部署 17 组「角色×对象」里引用非空的场景照旧按不动(实测:PR fix(objectql,spec): run the pre-delete reference check under the system identity #12596 已把该边界 pin 成断言,报错从 find 变 update)。
• B(set_null 清指针切系统身份,cascade 不切):清空引用指针视为引擎的完整性维护——与关系库 FK 的 SET NULL、Salesforce lookup 清空同构;删整行仍要操作人自己的删除权。代价:被引用表的一列会以系统身份被改写,操作人对该表的授权不再是这笔写入的门槛(引擎内部写入已有 __referentialFieldClear 标记,属主守卫与级联 set_null 冲突:非特权删除 sys_user 时 owner_id 级联置空被 #3004 守卫拦截(级联中途失败) #3023)。
• C(两者都切系统身份):级联删除也绕过操作人权限 ⇒ 「有 A 的删除权 = 能连带删掉自己无权删的 B 行」——数据销毁面的权限扩张,变更最大,需独立论证。

四棱:

• ① 项目长远合理性:B 与行业基线同构,把「引用完整性 = 引擎责任」的已裁原则做到写半边;A 把完整性动作留给每个部署自己拼权限矩阵,长期反复踩同一坑。
• ② 实际业务拉动:真实部署实测撞上(原始记录 steedos-labs/os-project-titanwind-ehr#1809),非投机面;边界影响已被 pin 成断言。
• ③ 防 AI 犯错:A 的失败形态是一句通用「您没有权限」——AI 配置权限时看不见「删除权还需引用表写权」的隐藏链,只能试错;B 让删除语义自含,出错面收敛到真正的数据销毁(cascade)一处,拒绝理由可以指名道姓。
• ④ 创业阶段不扩散:B 是把已裁原则延伸到同一动作的另一半,不新增能力面;C 的销毁面扩权应缓,除非产品语义明确要求。

推荐:B(回退项:A——零改动,但应把「删除需连带引用表写权」写进权限报错 guidance/文档,让隐藏耦合至少可见)。
置信缺口:系统身份 set_null 写入的审计归属(审计日志记操作人还是系统)与共享/RLS 规则外溢面未测;仓外部署是否依赖「cascade 需逐表授权」的现状未测;本分析依据本卡对裁决的引文,未逐字重读裁决评论原文。

裁后执行段(维护者只裁方向):裁 B/C ⇒ 认领评论 Clause-②: yes、契约复审档位派发,落点沿上一裁实现同面,翻转 PR #12596 的边界断言并补 cascade/set_null 各自的方向用例;裁 A ⇒ 关本卡,另立小卡把「删除需引用表写权」补进权限报错 guidance(S 级,domain:engine)。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded — Option B: set_null cleanup writes switch to system identity; cascade keeps the operator's own authority

Provenance: maintainer, 2026-08-27, PM chat decision-inbox batch 2 (adjudication session session_01DKWDdUJ2XNRESVVWUvcpnh), verbatim: 「同意」 — accepting the triage recommendation B (2026-08-26T16:19Z facet block); fallback A not needed; ⛔ C (cascade also system-identity) stays excluded — a data-destruction privilege expansion that would need its own justification.

Ruled: clearing a referencing pointer (set_null's UPDATE) is engine-owned referential-integrity maintenance and runs under system identity — completing the #12166 principle on the write half, consistent with the RDBMS FK SET NULL baseline and the __referentialFieldClear internal-write marker (#3023). Deleting whole referencing rows (cascade) still requires the operator's own delete authority on those rows.

Dispatch constraints:

1. Clause-②: yes — this expands the delete operation's accepted set; contract-review tier at dispatch.
2. The dev's FIRST measurements, before any code, are the two recorded confidence gaps: (a) audit attribution — what the audit trail records for the system-identity set_null write; it must remain attributable to the initiating operator's delete, not vanish into "system"; (b) RLS/sharing spillover of the elevated write. Either measuring badly ⇒ stop and report, never push through.
3. Flip PR fix(objectql,spec): run the pre-delete reference check under the system identity #12596's boundary pin (the constraint-1 assertion) and add direction cases for both arms: set_null succeeds without referencing-table write authority; cascade still refuses without delete authority on the referenced rows.
4. Lands on the same surface as 删除记录时「引用清理」用操作人身份查询引用表,读权不足即整体 403(应以系统身份执行) #12166's implementation; that ruling's other constraints are untouched.

State: needs-user-decision → pm:queue.

---

Generated by Claude Code