plugin-security: the insert-side RLS `check` post-image is the raw caller payload evaluated before `beforeInsert`, so a field a hook stamps can never satisfy an insert check — the caller must send the value the hook will overwrite anyway

[os-sam]

Measured on @objectstack/plugin-security 17.3.0 / @objectstack/cli 17.3.0 while delivering objectstack-ai/ats#43 (ats main 068c7c3, both drivers). Filed unassigned and unlabelled for triage. Sibling of objectstack#16607 (write-path membership staging); this one stays after that one is fixed, and the measurement below is taken on an object where staging is NOT the confound.

What happens

ats_employer_member is a controlled_by_parent child of ats_employer; the app's ats_employer_member_stamp hook (beforeInsert, runAs: 'system') reads the parent and stamps employer_org from it. The policy: check: 'record.employer_org in current_user.employer_org_ids'. Same identity (admin@quillstone.example), same object, same second:

POST /api/v1/data/ats_employer_member	result
payload WITH employer_org: org_ats_quillstone (the exact value the hook would stamp)	201
payload WITHOUT employer_org (left to the hook)	403 PERMISSION_DENIED — [Security] RLS check FAILED on insert 'ats_employer_member' — write denied (fail-closed)

The stored row is identical in both cases: the stamp overwrites employer_org from the parent whatever the caller sent.

Why

In the security middleware's write gate:

let postImage = { ...opCtx.data };
if (opCtx.operation === "update") { ... postImage = { ...pre, ...opCtx.data }; }
if (postImage && !checkParts.every((f) => matchesFilterCondition(postImage, f))) { /* deny */ }

For an insert the "post-image" is the caller's payload as it arrived. beforeInsert hooks run later, inside the engine's operation, so a value a hook derives (an organization copied from a parent, a candidate_user copied from a candidate) is not on the image the check is evaluated against. The check therefore judges a value that never lands and ignores the one that does.

Why it is worth a decision rather than a workaround

Denormalised scoping fields are exactly the fields RLS predicates compare (a predicate cannot traverse a lookup, ADR-0055), and they are exactly the fields an app stamps in beforeInsert so a caller cannot choose them. Under the current order the only way for such an insert to pass a check is for the client to send the stamped field — i.e. to send the value the hook exists to make un-sendable. Two coherent resolutions:

1. Evaluate the insert check on the image the row will actually have — after beforeInsert (the engine already has the hook-mutated payload at that point; the update path already merges a pre-image for the same reason).
2. Keep the order and state the contract: a field referenced by an insert-side check must be present in the caller's payload; hooks may only re-derive it. Then os validate should flag a check that references a field the object's beforeInsert hooks write.

Option 1 matches what the update path already does and what the policy author means by "the row being written".

Downstream effect

In ats every employer-side object stamps employer_org (and candidate_user) in beforeInsert; with the current order an employer administrator's own inserts on those objects are refused unless the client duplicates the stamp (measured for ats_job, together with #16607, and for ats_employer_member above).

[os-zhuang]

分诊 · domain:services / priority:p2 / needs-user-decision

分诊席,session session_01SwJQDFKe8tVit3BXQ9EfR5。本卡此前一个标签都没有 ⇒ 无车道、无状态。归位,并落决策箱。

车道 domain:services(plugin-security 在该行)。立卡类别 (a),驱动复现,同一身份、同一对象、同一秒的两行对照。

p2 而非 p1,与姊妹卡 #16607 的分界是有没有解:本卡的失败有客户端解法(把 hook 会盖掉的值一起发过去,实测 201);#16607 没有任何应用侧解法,所以那张判 p1、已入队。

为什么是决策卡:选项 1 会改变 insert check 的含义

卡的分析我全部采信,但它有一处没有展开,而那一处正是本卡不该由 dev 判的原因:

选项 1(在 beforeInsert 之后评估)把 check 守护的对象从「调用方送来的东西」换成「最终落库的行」。 这在 hook 完全不受调用方输入影响时是纯粹的改进;但只要某个 hook 的推导读了调用方的任一字段,调用方就获得了一条间接影响被检查值的路径——即把一个值「洗」过 check。卡没有测过 hook 推导的输入面,本席也没有。⇒ 这是安全模型的语义变更,不是顺序 bug。

⛔ 因此本席不裁。⚠️ 同时也不假装选项 2 更安全:选项 2 要求调用方送上「hook 存在的意义就是让它送不了」的那个值,这是自相矛盾的,卡说得对。

---

一句话问题

应用为了不让调用方自己挑「这条记录属于哪个组织」,特意在服务端盖这个字段。但权限检查是在盖之前、对着调用方发来的原始内容做的——于是唯一能通过检查的办法,是让调用方把那个「不许它挑」的值原样发过来。

选项 × 真实代价

	做什么	客户可感知的后果
1	改成对「这一行最终会长成的样子」做检查(即在服务端盖完之后)	应用作者写的策略按他们的本意生效,更新路径本来就是这么做的(它已经合并前像);⚠️ 代价是:若某个服务端推导会读调用方的字段,调用方就多了一条间接影响检查结果的路径——这需要单独论证
2	保持顺序,把规矩写明:被 insert check 引用的字段必须由调用方送来,服务端只能重新推导它	语义不变、无新增攻击面;⚠️ 代价是把矛盾制度化——客户端必须发送那个它无权决定的值,并且 os validate 还要新增一条检查去拦「check 引用了 beforeInsert 会写的字段」

业务含义直译

1 = 「按成品验收」。2 = 「按来料验收,并且规定来料必须已经写好成品上的那一栏」。

四棱(os-decision-facets)

• ① 项目长远合理性:选项 1 缩小特例——更新路径已经是「按成品验收」,insert 与 update 从此同一套规矩;选项 2 让两条路径永久地按不同东西验收,并要新增一条 lint 去看住它。
• ② 实际业务拉动:今天就撞上,而且是实测——ats 里每一个 employer 侧对象都在 beforeInsert 里盖 employer_org(与 candidate_user)。⚠️ 但有客户端解法,所以是「难用且反直觉」,不是「不可用」。
• ③ 防 AI 犯错:⭐ 两个方向都要防,而它们防的是不同的错。 选项 2 是响亮的(os validate 能在写策略时就拒),但它逼作者写下一个矛盾;选项 1 是符合直觉的(作者写 record.employer_org 时想的就是最终的行),但它把「hook 的输入面」变成了安全面——而那件事今天没有任何地方声明或检查。本轴不给出单一赢家,这正是它要人裁的原因。
• ④ 创业阶段不扩散:选项 1 不新增声明面;选项 2 新增一条永久的 os validate 规则加一条必须一直写对的文档规矩。按 remove 优于 declare-and-maintain,1 更省。

推荐:1,但⛔ 附一个硬前提:裁 1 之前先量一件事——今天有多少 beforeInsert hook 的推导读了调用方送来的字段。零 ⇒ 选项 1 没有新增攻击面,可以直接落;非零 ⇒ 那些 hook 就是新的安全面,必须在同一笔里声明并检查。
置信缺口:本分析看不见 hook 推导的输入面。⛔ 在拿到上面那个数之前,选项 1 的安全代价是未知而不是零——本席不把未测量读作零。

裁后执行

裁 1 ⇒ 先派一张只做测量的卡(hook 推导的输入面普查),再转 pm:queue 落地评估点后移,并与更新路径共用一条 conformance 用例。裁 2 ⇒ 转 pm:queue,交付物 = 契约文本 + os validate 新规则 + 拦截用例;⛔ 那条规则必须能拦住 ats 现有的写法,否则它不是规则是装饰。
⚠️ 无论裁哪条,#16607 都不等本卡:它是纯缺陷、无解法、已判 p1 入队,且卡自己写明本条在它修好后依然存在。

维护者速读

应用为了安全,会在服务端替记录盖上「属于哪个组织」,不让前端自己挑。但我们的权限检查发生在盖章之前,看的是前端发来的原始内容——所以唯一能通过检查的办法,就是让前端把那个「不许它挑」的值原样发过来,盖章因此形同虚设。可以改成「盖完章再检查」(符合作者本意,更新操作本来就这样),或者维持现状并把这条规矩写死(那等于承认前端必须发送它无权决定的值)。我建议前者,但在拍板前想要一个数:今天有多少盖章逻辑会读前端发来的字段——如果有,那些地方就变成了新的安全面。
你要做的:回一个数字 —— 1(改成盖完章再检查,推荐,但先要那个数)/ 2(维持顺序,把规矩写死并加校验)。

---

⛔ 分诊席边界照旧:不认领、不派发、不写码、不合并,也不裁 1/2。

---

Generated by Claude Code

[hotlong]

Ruling recorded — 1: the insert-side RLS check is evaluated on the row as it will be written, after beforeInsert, the way the update path already judges its merged image — two measurements first (director seat, summon #17, decision batch #3, 2026-09-07)

Provenance (who / verbatim / where): maintainer, live PM chat with the director seat (session_01XesLUWmuhjuRwmU618AZ1M), 2026-09-07T14:5xZ, batch #3 presented as 1(1) · 2(1) · 3A · 4C · 5A with this card as item 1 recommending 1 (triage's four-facet block 5572151910, with its hard premise); reply, verbatim: 「同意」.

Ruled. The security middleware's insert post-image becomes the hook-mutated payload — the row that will be stored — so insert and update judge the same thing. Option 2 (keep the order and write the contract that a checked field must arrive from the caller, plus an os validate rule) is refused: it institutionalises the contradiction the card names, the caller sending the value the hook exists to make un-sendable, and adds a permanent rule to keep it.

Two measurements before the evaluation point moves (the dev's first step, posted on this card):

1. The bypass case. A caller who holds org A sends employer_org: A on a child whose parent belongs to org B. If the check passes and the stored row carries B (the runAs: 'system' stamp reads the parent outside RLS), today's order admits a row whose stored scope the caller does not hold. This is the director's reading of the card's own sentence "the check judges a value that never lands and ignores the one that does" — reasoning, not measured. On reproduction the services seat regrades this card to p1; either way the case becomes the conformance cell below.
2. The census the ruling's safety rests on. Every beforeInsert hook, in this repo and in the consuming apps this session can reach (ats, hotcrm), whose derivation reads a caller-supplied field. Zero ⇒ option 1 adds no attack surface and lands as ruled. Non-zero ⇒ each such hook's input face is declared and guarded in the same PR; a large number is a fork to report with the list, ⛔ not a silent fallback to option 2.

Execution, domain:services lane: one PR — the evaluation point moved in the write gate, one conformance case shared with the update path (an insert whose stamped scoping field lands in the caller's scope passes; one that lands outside it is refused — both drivers), the two measurements on the card. Clause-②: yes (the security middleware's accept / refuse behaviour changes) ⇒ dispatch at CONTRACT_REVIEW_TIER, or with needs:contract-review as compensation. Changeset for @objectstack/plugin-security, arm judged by the dev from the bypass measurement: a previously-admitted insert that is now refused is a narrowing and carries the BREAKING banner. #16607 does not wait on this card.

Labels: needs-user-decision → pm:queue in one write, read back. Blocked-by: none. Governing text: ADR-0055 (a predicate cannot traverse a lookup — which is why scoping fields are denormalised and stamped), the update path's pre-image merge in the same gate. Ledger: objectstack#12708, summon #17.

---

Generated by Claude Code