删除记录时「引用清理」用操作人身份查询引用表,读权不足即整体 403(应以系统身份执行)

[baozhoutao]

一句话

删除一条记录时,平台的「删除前引用清理」用当前操作人的身份去 find 每一张引用表;操作人只要对任何一张引用表没有读权限,整个删除就 403 —— 与记录是否真的被引用无关(空库也 403)。期望这一步用系统身份执行。

版本

@objectstack/*@17.2.0(driver-sql / objectql)

最小复现

1. 对象 A 被对象 B 的一个 lookup 字段引用;
2. 角色 R 对 A 有完整删除权限(含 modifyAllRecords),对 B 无读权限(access: private,未授 read);
3. 用角色 R 的账号删除一条 A 记录(B 表可以是空表,零引用);
4. 实际:DELETE /api/v1/data/<A>/<id> → 403 PERMISSION_DENIED;前端提示「您没有执行此操作的权限」。
5. 对照:仅给 R 补上 B 的只读权限(删除权分毫未动),同一操作立即 200。

服务端日志(删除时刻)

ERROR Delete operation failed
 object: os_tianshun_ehr_product
 developerMessage: [Security] Access denied: operation 'find' on object
 'os_tianshun_ehr_andon_record' is not permitted

为什么这是问题

• 引用清理/引用检查是平台内部的数据一致性动作,不是操作人发起的查询;要求操作人对所有引用表有读权,等于「删除权 = 删除权 + 全部引用表读权」,而这层耦合在权限配置界面上完全不可见;
• 实际项目里按「谁的台账给谁看」收紧读权后,我们盘出 17 组「角色×对象」是界面上有删除按钮、一按必 403 的状态;
• 报错文案只有一句通用「没有权限」,不指明是哪张引用表的读权被拒,用户与管理员均无法自查(顺带的文案诉求)。

期望行为

删除前的引用清理查询以系统身份(isSystem context)执行;操作人的权限只应决定「能不能删这条 A」,不应外溢到引用表的可读性。

出处

应用项目实测记录(含 12 张 UI 截图、A/B 根因验证):steedos-labs/os-project-titanwind-ehr#1809

[os-trump]

Triage: lands in packages/objectql (delete flow's pre-delete reference-cleanup query) and/or packages/drivers/driver-sql; rationale: the reference-existence check that gates delete currently runs with the caller's identity instead of a system context, so a caller with full delete rights on the target object but no read grant on any referenced object gets a blanket 403 regardless of whether a reference actually exists. This is the same isSystem-context pattern already used for read-only integrity checks elsewhere in this package (see packages/objectql/src/integrity/dangling-reference-audit.ts), so the fix has in-repo precedent and does not expose any new data to the caller — the caller only ever learns pass/fail on their own delete, not reference-table contents. Concrete repro with a clear before/after control is given in the issue body. No open design question.
Size/model suggestion: small, single-seat fix.

---

Generated by Claude Code

[os-trump]

State repair + escalation record (triage seat, session session_01Rpg1AKeaL6phq5Ve3yfMMZ): pm:queue removed in the same stroke — needs-user-decision and an active queue label cannot coexist (a queued card that must never be dispatched is a lying queue). This supersedes the 11:49Z triage note's "No open design question": the fix relaxes a permission check (delete-time reference cleanup switching from caller identity to system identity), which is a security/permission-boundary change and sits on the human floor — maintainer's call, not auto-adjudicable, however good the in-repo precedent is.

以下按落卡模板补全决策分析(中文,决策箱勤务):

一句话问题:管理员给了某个角色完整的删除权限,用户界面上也有删除按钮,但只要这个角色对任何一张「引用了本对象」的表没有读权限,一按删除就整体报「没有权限」——哪怕引用表是空的。实测部署里有 17 组「角色×对象」处于这种状态。

前提(re-check 命令):

• 引用清理以操作人身份跑 find:服务端日志 [Security] Access denied: operation 'find' on object '<引用表>' is not permitted(issue 正文,A/B 对照实测);
• in-repo 系统身份先例:git grep -n isSystem origin/main -- packages/objectql/src/integrity/ 应命中 dangling-reference-audit。

选项 × 真实代价:

• A. 引用清理以系统身份执行,报错点名被引用对象 —— 业务上 = 「有删除权就能删」,和主流 CRM 一致;操作人只看到自己删除的成败,看不到引用表内容。代价:操作人可从「删除被引用挡住」推断存在引用记录(删除语义固有信息,非新泄露面)。
• B. 维持现状,只改报错文案点名缺哪张表的读权 —— 业务上 = 管理员必须给每个可删角色配齐全部引用表读权;「谁的台账给谁看」的收权被迫回退,17 组配置逐个补。代价:权限配置爆炸且耦合仍不可见。
• C. 不动 —— 界面有删除按钮、一按必 403,用户与管理员均无法自查。

四棱卡面(机器标记,按字面 grep):<!-- os-decision-facets -->

• ① 项目长远合理性:引用完整性检查是平台内部一致性动作,不是操作人发起的查询;A 有 in-repo 先例(dangling-reference-audit 的 isSystem 模式),且消除「删除权隐含全部引用表读权」这个在权限界面上不可见、不可配置的隐藏耦合 —— 缩小特例。
• ② 实际业务拉动:真实部署实测撞上(17 组角色×对象、空表也 403、含 12 张截图的 A/B 根因验证)—— 非投机面,今天就有用户按不动删除按钮。
• ③ 防 AI 犯错:现状报错只有一句通用「没有权限」,AI 和管理员都无法自查根因;A 配合点名被引用对象的报错是响亮失败,优于静默的权限外溢。
• ④ 创业阶段不扩散:纯缺陷修复方向,不新增能力面;因触及权限边界语义,按人工地板呈报而不代裁。

推荐:A(回退:B)。置信缺口:本分析未实测是否有现存部署依赖 403 兜底行为(把「引用表读权」当作变相的删除闸);spec/文档侧未见声明该耦合为契约。

裁后执行(你不用管细节):裁 A ⇒ 摘 needs-user-decision 换 pm:queue,派发令按 dangling-reference-audit 的 isSystem 先例限定在删除前引用清理查询一处,报错文案点名被引用对象;因属权限语义变更,派发档位与复核从严(引擎席条款申报)。裁 B/C ⇒ 转文案卡或关闭,出处记录本评论。

回一个字母即可;「A,但 X」= 附加约束一并进派发令。

---

Generated by Claude Code

[os-steve]

Maintainer ruling recorded — A: delete-time reference cleanup runs under the SYSTEM identity

Provenance: maintainer, 2026-08-26, live PM chat (decision-inbox batch 1, presented with the global-platform comparison by the skills seat, session session_01JANH3y7qe3MD8aLaLXci8N), verbatim: 「A」.

The industry comparison that grounded the ruling, kept with it: referential-integrity actions (check / clear / cascade / restrict) are engine responsibility executed under system identity on every mainstream platform — the RDBMS FK baseline (RESTRICT/SET NULL/CASCADE run by the engine regardless of the deleter's SELECT grants), Salesforce (lookup clearing and cascade-delete documented as bypassing sharing; restrict errors name the blocking relationship), Dataverse (platform-side Remove Link/Restrict/Cascade, with Cascade User-Owned existing precisely as the explicit NARROWING), ServiceNow and Odoo alike. The current caller-identity behaviour is the outlier and composes badly: it silently makes "delete permission" mean "delete + read on every referencing table", invisible in the permission UI.

Four binding implementation constraints, accepted with the ruling — these go into the dispatch brief verbatim:

1. Scope pinned: ONLY the pre-delete reference-cleanup/reference-check queries switch to system identity, following the in-repo isSystem precedent (packages/objectql/src/integrity/dangling-reference-audit.ts). Nothing else about the delete path changes identity.
2. The error names the referenced OBJECT, never record contents — one notch more conservative than Salesforce: the caller learns "blocked by / cleared references on object X", nothing about rows.
3. Audit records both halves: triggered-by = the deleting operator, executed-as = system (the Salesforce/Dataverse ledger shape).
4. Behaviour vs identity separation: if the spec later declares per-relationship on-delete behaviour (restrict / set-null), behaviour follows the declaration — the identity stays system, unconditionally.

Confidence gap recorded as presented: no measurement of deployments relying on the 403 as a de-facto delete gate; under the industry baseline that usage is itself non-standard and should be expressed as an explicit restrict, not a permission side effect.

State transition in the same stroke: needs-user-decision → pm:queue (domain:engine stands — the engine seat dispatches; clause discipline per that lane's standing rules for a permission-semantics change, review from严).

---

Generated by Claude Code