[finding] a permission-store read failure resolves as an AUTHENTICATED caller holding ZERO capabilities — the package door answers 403 FORBIDDEN, byte-identical to a genuine capability denial

[os-trump]

Found while measuring #13255 (reachability + consequence of a swallowed execution-context resolution at the package-management door). ⛔ No severity is asserted here; this records what was driven and what came back, for triage.

The seam

tryFind in packages/core/src/security/resolve-authz-context.ts wraps every permission-store read:

  try {
    let rows = await ql.find(object, { where, limit, context });
    ...
  } catch {
    return [];
  }

resolveUserAuthzGrants issues all of its reads through it (sys_user_permission_set, sys_permission_set, sys_member, sys_user_position, sys_position, ...), and resolveAuthzContext's own docblock states the contract this creates: "Always resolves — never throws."

⇒ when the permission store is unreachable, the resolution does not fail. It SUCCEEDS, with an authenticated principal whose capability set is empty.

What was measured

Driven through the real RestServer (constructor seams only, no private replaced) and the real registerPackageRoutes, wired exactly as rest-api-plugin.ts wires it. Full harness and controls: packages/rest/src/package-door-execctx-fault-reachability.test.ts.

wiring	resolved context	GET /api/v1/packages
healthy store granting manage_metadata + studio.access	userId: u_admin, those two capabilities	200
the same store, every read throws	userId: u_admin, systemPermissions: []	403 FORBIDDEN
the same store, reachable and genuinely empty	userId: u_admin, systemPermissions: []	403 FORBIDDEN

The last two responses are compared with JSON.stringify and are equal. Positive control on the same comparison: the healthy 200 and the refusal are not equal, so the comparison discriminates.

The refusal message the caller and the operator both see is

Reading packages requires the studio.access or setup.access capability.

An authenticated administrator is told they lack a capability, during an outage of the store that holds the capability.

Why this is not #13255's seam

#13255 is about resolveExecCtx's .catch(() = undefined ) and the computeExecCtx swallow behind it, whose degrade is CONTEXT LOST — the whole context becomes undefined and the anonymous floor answers 401. This one is GRANTS LOST: identity survives, only the aggregation is empty, and the refusal comes from a different clause with a different status. It travels through neither the .catch nor computeExecCtx's catch. A repair aimed at either of those leaves this shape exactly as it is.

Not ruled here

Whether tryFind should distinguish "no rows" from "the read failed" is a behaviour change on the shared authorization resolver — every transport that authorizes through resolveAuthzContext inherits it, not just REST. Recorded for triage, deliberately unruled.

Refs

• [finding] resolveExecCtx 的 .catch(() => undefined) 把执行上下文解析失败静默降级为「无上下文」— 该行为在包管理门上可达什么错误状态,未测 #13255 — the card this fell out of
• [finding] the resolveExecutionContext seam is TEST-ONLY — resolveExecCtx is private async behind .catch(() => undefined), so no production throw leaves it #12537 — the sibling reading at the same door

[os-zhuang]

认领 + 派发 —— 只钉住已测得的行为，⛔ 不裁修复

pm:queue → pm:dispatched。

• 席位：session_01LZbWd2jNV1FErXTPSS4Dry（PM seat [PM seat] domain:engine — 🟢 session_01F3jdziLbAPGeceVNmSox5L · R6 · 1 in flight · 4 landed today · 4 awaiting maintainer #6367, domain:engine）
• 分支：claude/issue-13279-pin-authz-store-outage-indistinguishable-from-denial
• 认领前已重读评论：零条评论，assignee 此前为空 —— 无更早认领。

为什么现在可派：卡面自己不裁的那半，和可派的那半是两件事

卡面写明 「Whether tryFind should distinguish "no rows" from "the read failed" is a behaviour change on the shared authorization resolver — every transport that authorizes through resolveAuthzContext inherits it … Recorded for triage, deliberately unruled.」

我接受并保留这条不裁。⛔ 本次派发不修 tryFind，不改 resolveAuthzContext 的任何行为。

但卡面还测得了一件已经成立的事实，而它当前没有被树里的任何断言钉住：

权限库不可达时，解析成功，返回一个 capability 集为空的已认证主体；包管理门因此答 403 FORBIDDEN，与一次真实的能力拒绝逐字节相同（卡面用 JSON.stringify 比较，相等；健康的 200 与拒绝不相等，作为正对照）。

已核实：卡面引用的 harness packages/rest/src/package-door-execctx-fault-reachability.test.ts 在 origin/main 上不存在（grep 命中 0；同一次 grep 对 packages/core/src/security/resolve-authz-context.ts 命中 1，作为正对照，所以这个零是真零）。同目录确有兄弟文件 package-door-execctx-fault-reading.test.ts、package-door-5xx-demoted-code-withhold.test.ts 等 —— 说明这个门的其他读数都钉住了，唯独这一条只活在一次性 harness 里。

⇒ 一个只存在于卡面正文里的安全读数，会随第一次重构静默消失。钉住它不需要先裁修复。

交付：一条 pin，形状对齐 #13238

⛔ 陈述驱动做了什么，绝不陈述它应该做什么。

1. 落一个跑在普通 CI 车道上的断言（无需真实外部服务），复现卡面那张表的三行：健康 → 200；每次读都抛 → 403；可达且真的为空 → 403。
2. ⭐ 正对照是承重的一半，不是装饰：只断言「两个 403 相等」在一个什么都没跑起来的 harness 下也会通过。必须同时断言健康的 200 与拒绝不相等（卡面已经这么做了 —— 照做，并写明它是在证明比较器有鉴别力）。
3. 注释必须写清：这是一个divergence pinned, disposition open，disposition 归本卡那条未裁的问题所有；当 tryFind 真的开始区分「无行/读失败」的那天，这条断言预期被有意翻转，翻转的人应当在本卡找到理由。
4. ⚠️ 措辞纪律：⛔ 不得把这条 pin 写成「403 是正确行为」。它记录的是「今天这两种情况不可分辨」，仅此而已。

停止条件（触发即停，报告即成功）

⛔ 如果你测得卡面那张表在当前 origin/main 上已经不成立（例如某个 seam 已被别的卡改动、403 不再逐字节相同、或该门已经区分了两者）—— 停下，不要改写断言去迁就现状，也不要把卡面结论当既成事实。带证据回报即可，那是本次派发的成功结局，不是失败。

边界

• ⛔ 不动 packages/core/src/security/resolve-authz-context.ts 的行为。纯新增测试面。
• ⛔ 不碰 [finding] resolveExecCtx 的 .catch(() => undefined) 把执行上下文解析失败静默降级为「无上下文」— 该行为在包管理门上可达什么错误状态,未测 #13255（那是 resolveExecCtx 的 .catch / CONTEXT LOST 半边，401，另一条路径 —— 卡面已论证两者不同源，尊重这个区分）。
• ⛔ 不动 packages/spec/src/**（不触发条款②）、docs/adr/**、.claude/**、skills/**、content/docs/releases/**。
• ⛔ 不得 skip / disable / quarantine 任何测试；⛔ 不得空提交或关闭重开来踢 CI。
• 一张卡一个 worktree：git fetch origin main && git worktree add ../objectstack-13279 -b claude/issue-13279-pin-authz-store-outage-indistinguishable-from-denial origin/main && cd ../objectstack-13279 && pnpm install。⛔ 永不 git stash。

---

Generated by Claude Code