共享规则 hook 对谓词式(multi)写入不重算:`if (!id) return` 让 `sys_record_share` 授权在批量更新后变陈旧

[os-zhuang]

在 #4757 的「同形状排查」中发现。未认领,归属 plugin-sharing,不在 #4757 的 PR 范围内。

现象

packages/plugins/plugin-sharing/src/rule-hooks.ts 的 bindRuleHooks 为每个有共享规则的对象绑定 afterInsert / afterUpdate,处理函数第一步就靠单条记录 id 定位要重算的行:

const data = ctx?.result ?? ctx?.input?.data ?? {};
const id = String((data as any)?.id ?? ctx?.input?.id ?? '');
if (!id) return;
await service.evaluateAllForRecord(objectName, id, SYSTEM_CTX as any);

packages/objectql/src/engine.ts 的 update() 只在 where.id 是标量时提取 input.id;谓词式(multi: true)更新走 updateMany,input.id 为 undefined,input.data 里通常也没有 id,ctx.result 是受影响行数而非行本身。于是批量更新的每一行都不会重算共享规则。

后果与 #4757 同向 —— 是授权侧的 fail open,只是路径更隐蔽:

• 一条基于 criteria 的共享规则给记录发过 sys_record_share 行;
• 管理员用 multi: true 批量把这些记录改成不再匹配该规则的状态(改 owner、改 stage、改 region…);
• 重算没有发生,sys_record_share 行原样留在表里 → 本应失去访问权的用户继续能读/能改这些记录。

反向也一样(批量改成匹配规则却没发出共享),但那一侧是「少给权限」,危害小得多。

复现方向

对某对象定义一条 criteria 共享规则,插入命中的记录(hook 正常发共享),然后:

await ql.update(obj, { where: { region: 'east' }, multi: true, data: { region: 'west' }, context: adminCtx });

再查 sys_record_share:原来的共享行仍在,evaluateAllForRecord 一次都没被调用。

建议修法

把「单条 id」的入口扩成「本次写入匹配的行集合」:在 beforeUpdate 阶段用谓词(带上界,超限告警或失败关闭)解析出受影响的 id 列表并暂存到 hook ctx(primary-bu-projection.ts 的 STASH_KEY 就是这个模式),afterUpdate 再逐行 evaluateAllForRecord。上界参考 attachment / comment 守卫的 1000 行。

需要维护者裁定的一点:超过上界时该怎么办 —— 是拒绝这次批量写入(fail closed,与 #4757 的姿势一致),还是放行但记一条显式告警并标记重算待办(共享规则重算本身是异步可补偿的)。这决定了它算「守卫」还是「投影」,建议在动手前先定。

相关

• installAttachmentAccessHooks does not authorize an UNSCOPED multi-delete: no id + no where reads as "nothing to authorize" and deleteMany runs over the whole table #4757 —— sys_attachment 的 beforeDelete 无作用域多行删除(同一 fail-open 家族,已修)。
• 审批记录锁 bindApprovalLockHook 对谓词式(multi)更新完全失效:if (!id) return 把「没解析到行」当成「允许」 #4778 —— 审批记录锁对谓词式更新失效(同一排查)。
• rule-hooks 只绑了 afterInsert / afterUpdate,没有 afterDelete:记录删除后 sys_record_share 行会成为孤儿。今天危害有限(记录已不存在),但若 id 可复用就是真实的越权,一并记在这里。

[os-zhuang]

分诊:标 needs-user-decision,暂不派发。

「行集合超过上界时怎么办」这一问过了升级门槛,理由不是它难,而是仓内两条既有规范正好指向相反方向,而选哪条取决于一个尚未回答的分类问题:

• 按授权守卫看:sys_comment has no record-level authorization: any org member reads and writes comments on records they cannot see #4630(sys_comment)、installAttachmentAccessHooks does not authorize an UNSCOPED multi-delete: no id + no where reads as "nothing to authorize" and deleteMany runs over the whole table #4757(sys_attachment)都已确立 fail closed —— 解析不出行集合就拒绝写入;
• 按投影看:primary-bu-projection.ts 明确是 best-effort,靠下次写入或 boot backfill 自愈,从不拒绝写入。

rule-hooks 挂的是 afterInsert / afterUpdate,形式上是投影;但它维护的 sys_record_share 是授权数据,陈旧的后果是有人保留了本该失去的读写权。所以它两边都像,这正是要你拍板的地方。

方案与两轴

A. 超上界即拒绝批量写入(fail closed,与 #4757 同姿势)

• 长远合理性:🟡 一致性好,但代价被低估了 —— 它让一个与业务无关的实现上界(共享规则重算的 1000 行)变成业务写入的硬限制。一张 5000 行的表做一次合法批量改 region 就会被拒,而用户看到的错误来自一个他从未配置过的子系统。这不是收紧契约,是把内部限制泄漏成对外语义。
• 防 AI 写错:🟡 拒绝是响亮的,不会静默。但 agent 写批量数据订正脚本时会撞上它,而错误信息指向共享规则 —— 大概率被理解成「共享规则坏了」,引向错误的排查方向。

B. 放行 + 显式告警 + 标记重算待办(issue 里的另一选项)

• 长远合理性:❌ 这是「声明 ≠ 强制」的教科书形态:系统声明「共享规则决定谁能看见这条记录」,而实际上在批量写之后,一段不确定的时间内它不决定。「待办」若没有真正的补偿执行者,就是一个永远不会被兑现的承诺。
• 防 AI 写错:❌ 最差。越权窗口静默存在,而唯一的信号是一条 warn —— 与 [convention] best-effort 降级导致"看起来正常、实则不持久"时不应记 warn——把 #4460 的点状修复定成规则 #4632 要修的形状同族。

C.(我补的第三条)超上界时同步撤销、异步重发

超上界时不拒绝写入,而是同步删掉受影响行集合的 sys_record_share 行(集合式删除,一条语句,没有 1000 行上界问题),然后异步重跑 evaluateAllForRecord 把该有的共享补回来。

• 长远合理性:✅ 它承认了这里真正的不对称:多给权限是安全事故,少给权限是可用性抖动。撤销是集合操作、廉价且无上界;重发是逐行的、昂贵且需要上界。把两者拆开,让昂贵的那一半异步,而让安全攸关的那一半永远同步且完整。写入不被拒绝,内部上界也不泄漏成业务语义。
• 防 AI 写错:✅ 失败方向是安全的 —— 异步重发挂了,结果是有人暂时少看见东西(会被报障、会被发现),而不是有人多看见东西(不会被报障、不会被发现)。这正是「让错误响亮」在授权面的正确形态。
• 代价要说清:批量写之后到重发完成之间,合法用户会短暂失去访问;evaluateAllForRecord 需要能被异步重入调度(如果目前没有这个执行路径,C 的成本高于 A 和 B)。

我的建议

倾向 C,若因为没有可靠的异步执行路径而做不了,则退 A 不退 B —— B 的问题不是保守或激进,而是它让系统对自己的授权状态说谎。

请你定的其实是一句话:共享规则重算,是授权守卫还是投影? 定了它,上界策略就跟着定了,#4778 之后这一族剩下的几处也有了统一判准。

顺带(不影响上面的裁定)

issue 末尾提到 rule-hooks 没有绑 afterDelete,sys_record_share 会留孤儿行。同意「今天危害有限」,但请注意这个前提是id 不可复用 —— 那是个没有被任何门禁保护的假设。如果哪天引入 id 复用(或 app 自定义主键、导入时保留原 id),这些孤儿行会立刻变成真实越权。建议无论上面选哪条,都把 afterDelete 补上:它是廉价的、没有上界问题的,而且它消除的是一个「依赖某个未被强制的假设」的隐患。

---

Generated by Claude Code

[claude]

维护者裁定(2026-08-04):方案 C —— 超上界时同步撤销(集合式删 sys_record_share)+ 异步重发;若核实仓内无可靠的异步重入执行路径,退 A(fail closed),不退 B。

派发说明:dev 第一步核实异步执行路径(job/queue/boot backfill 类)是否存在且可靠 —— 存在则实现 C,不存在则实现 A 并在 PR body 写明核实证据。上界沿用 attachment/comment 守卫的 1000 行先例。afterDelete 孤儿行问题(issue 末尾记录的)一并处理或单独立案,由 dev 按工作量判断。

摘 needs-user-decision,本轮派发。

---

Generated by Claude Code