Skip to content

check-single-authz-resolver 检查 (1) 的判据词表已被 ADR-0090 D3 改名废掉:sys_user_role 全仓 0 命中,门禁结构上抓不到任何重复解析器 #6286

Description

@hotlong

#6070(PR #6282,放宽 walk 的扩展名过滤)复测"放宽后现状仍绿"时量到的,与该 PR 正交、不在其申报面内,故单独记录。

⚠️ 这条比 #6070 严重一档:#6070 是"语料少读了 12 个文件"(休眠,今天无漏判);这条是判据本身已经匹配不到任何东西 —— 门禁的检查 (1) 今天在结构上无法变红

观察

scripts/check-single-authz-resolver.mjs 检查 (1) 的启发式(audit() 内):

if (src.includes('sys_user_role') && src.includes('sys_user_permission_set')) { /* 报重复解析器 */ }

sys_user_role 这张表 已经被 ADR-0090 D3 改名:sys_rolesys_positionsys_user_rolesys_user_position(15 个包的 CHANGELOG 各记了一次;packages/plugins/plugin-security/src/objects/sys-user-position.object.ts:9 的注释原文 "ADR-0090 D3; formerly sys_user_role")。

实测(origin/main @ f6609e6,语料按 PR #6282 放宽后的 1487 个文件)

语料文件数 1487
sys_user_role 的文件 1(且仅出现在 sys-user-position.object.ts 的 "formerly" 注释里)
sys_user_permission_set 的文件 32
同时命中两词(= 启发式能抓到的文件) 0
同时含 sys_user_position + sys_user_permission_set(当前真实词表) 20

关键一条:规范解析器自己也不触发自己的启发式packages/core/src/security/resolve-authz-context.ts 读的是 sys_user_position(:317)与 sys_user_permission_set(:341)—— 没有 sys_user_role

后果

  1. 检查 (1) 是个 phantom check:今天照抄规范解析器真实读的那两张表写一个重复解析器,门禁一路绿灯放行 —— 而这正是该门禁立案要防的原始 bug(REST server 自带一份漂移的解析器)。
  2. ALLOW 名单整体已死:两条豁免(CANONICALdefault-permission-sets.ts)豁免的是一条永远不会触发的启发式。
  3. 属于 check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690 写下的那一族反面:「提取失败必须红」—— 这里是"判据匹配不到任何东西,却照常印绿"。三个 check:* 脚本的扫描根消失时返回空数组而不是报错 —— 目录一改名,门禁在零个文件上报绿 #4930 / check-single-authz-resolver 的扫描语料没有下限断言:根解析成功但一个文件都没扫到仍然绿(observation) #5916 关的是"没读到"(语料),这条是"读到了但judgement 词表已经过期"(判据),两侧都封住才算完整。

为什么不在 PR #6282 里顺手改(以及为什么不是一词替换)

  • 范围:check-single-authz-resolver 的 walk 只收 .ts,packages/ 下 12 个 .mts 从不被扫描(observation) #6070 的分诊把范围钉死在扩展名过滤 + 回归断言,判据词表是另一件事(改语料不改裁决,改判据必然改裁决)。
  • 不是一词替换:把 sys_user_role 直接换成 sys_user_position,今天会命中 20 个文件,其中大部分显然不是解析器(4 个 generated translations、object.zod.ts / permission.zod.ts / component.zod.ts 等 schema、platform-object-names.ts 常量表)。所以需要先决定启发式的形状(是否收窄到 security/ 落点、是否改判"同时 query 两张表"而非"同时提到两个字符串"),再配一份重新策展的 ALLOW。这是个有取舍的判断,不该在一个申报面是"扩展名过滤"的 PR 里塞进去。

候选修向(供分诊参考,未实现)

除了更新词表本身,值得一并加的是结构性的防复发:self-test 今天只在合成 fixture 上证明启发式能抓能放,没有任何断言要求启发式在真实仓库里仍然匹配得上规范解析器 —— 这正是这次改名能悄无声息废掉判据的原因。加一条真实仓库上的阳性对照(「CANONICAL 必须被检查 (1) 的启发式命中」),下一次表改名就会当场红,而不是等到有人来量。

同族先例:check:engine-double-contractcheck:error-code-casing 这类"判据 + 语料"双要素门禁都吃这个亏 —— 语料侧有下限断言(#5916),判据侧没有阳性对照。

相关:#6070 / PR #6282(语料侧,扩展名过滤)、#5916 / PR #6056(按根下限)、#4930 / #4916(死根按名报错)、#4690(「提取失败必须红」出处)、ADR-0090 D3(改名来源)。

由 os-dev 座位在 #6070 施工中量到并按 Prime Directive #10 立案,未认领,交分诊定级。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions