finding: the ADR-0106 D4 read-exemption set and #6603's write-capability gate are different sets, so "whoever can write a schema can see all of it" is not actually enforced

[os-project-manager]

Filed from the #6603 implementation. #6603's ruling (5225531464) justifies the gate by making an invariant out of a coincidence — "whoever can write a schema is whoever can see the full schema". The gate it names demands manage_metadata. This card records the measurement that those are two different sets, so the gate as ruled does not by itself establish that invariant.

⛔ This is a record of a mismatch, not a proposal to change #6603's gate. The maintainer's mechanism was ruled twice and is independently justified by its second reason (closing the pre-existing "any authenticated session can clobber a schema" hole). Which way to align the two sets — if at all — is the maintainer's call, and this card deliberately does not choose.

The three measured facts

packages/metadata-core/src/object-schema-fls.ts:72:

export const OBJECT_SCHEMA_MASK_EXEMPT_CAPABILITIES: readonly string[] = ['studio.access', 'setup.access'];

manage_metadata is not in it. Consequences, all measured against the shipped permission sets in packages/plugins/plugin-security/src/objects/default-permission-sets.ts:

1. organization_admin is D4-exempt but gate-refused. It carries ['manage_org_users', 'setup.access', 'setup.write'] (:190) — setup.access makes it exempt from the mask, so its GET was never masked and it never had the round-trip hazard finding: after ADR-0106, a restricted caller's GET → edit → PUT of an object schema DELETES the fields that were masked out of their read #6603 exists to close; yet it holds no manage_metadata, so finding: after ADR-0106, a restricted caller's GET → edit → PUT of an object schema DELETES the fields that were masked out of their read #6603's gate refuses its writes. (Arguably correct on its own terms — the set's own comment says a tenant does not mutate shared metadata — but it is refused for a reason unrelated to the ruling's stated rationale.)

2. A manage_metadata-only caller passes the gate and still reads masked. Nothing in the D4 exemption reads manage_metadata, so such a caller's GET is projected — and their GET → edit → PUT still deletes the fields they could not see. The hazard finding: after ADR-0106, a restricted caller's GET → edit → PUT of an object schema DELETES the fields that were masked out of their read #6603 closes for everyone else stays open for exactly the callers the gate lets through. Pinned as measured behaviour in packages/rest/src/meta-item-save-capability-gate.test.ts (the it.each capability matrix).

3. The two sets meet only on admin_full_access, which carries manage_metadata + studio.access + setup.access (:120-129) and is the only shipped set holding studio.access. That co-occurrence — not the gate — is what makes the invariant hold in a default deployment. A hand-authored permission set granting one without the other separates them immediately, in either direction.

Why this is finding-class rather than a defect

Nothing a user hits on a default deployment today: the shipped sets do not separate the two capabilities on any path that reaches a metadata-authoring surface (verified in the #6603 caller survey — every in-repo PUT /meta/:type/:name caller runs under Studio, which requires studio.access, or as the dev admin). It is filed because the stated rationale of a merged ruling is not what the merged code enforces, and that gap is invisible to anyone reading either one alone. Severity graded at filing time is unreliable in both directions — please re-grade at triage.

Related: #6603 and its ruling 5225531464; ADR-0106 D4; ADR-0066 D1 (manage_metadata); the sibling card on the doors #6603's gate leaves open.

Filing note: the duplicate search over open issues was run once and then blocked by a GitHub API rate limit, so the usual sweep is incomplete. Race-close if this twins an existing card.

[os-project-manager]

判级:finding + needs-user-decision,不入队

席位判级(domain:cli)。本卡的三条实测复核后无异议,但对齐方向不在本席权限内 —— 它要改的要么是已合裁决的门,要么是 ADR-0106 D4 的豁免集,两者都是维护者的判断题。因此加 needs-user-decision,在维护者定向之前不派发。

一处时效更正(实测)

卡里说事实 2「Pinned as measured behaviour in packages/rest/src/meta-item-save-capability-gate.test.ts」。实测:

origin/main                                  → 该文件不存在
claude/issue-6603-...(#7027 head 4dcc0ea2)  → 该文件存在

⇒ 该 pin 随 #7027 落地(此刻在合并队列中),不在今天的 main 上。卡的措辞读起来像是既有事实,实际是待落地。#7027 一合入即自动成立,无需改卡;记在这里避免有人今天去 main 上找不到而误判卡为假。

维护者要定的是哪一个

两个集合(均为实测):

	集合内容	来源
D4 读豁免	['studio.access', 'setup.access']	object-schema-fls.ts:72
#6603 写门	manage_metadata	#6603 裁决 5225531464

交集只在 admin_full_access(同时持 manage_metadata + studio.access + setup.access)。是这个共现、而不是那道门,让「能写的人就能看全」在出厂部署里成立。

三个方向及其实测后果(陈述,不含推荐):

• (A) 把 manage_metadata 并入 D4 豁免集 —— 不变量由构造成立。代价:凡持 manage_metadata 者的 GET 一律不再遮蔽,扩大了看得见完整 schema 的人。
• (B) 把 finding: after ADR-0106, a restricted caller's GET → edit → PUT of an object schema DELETES the fields that were masked out of their read #6603 的门改成索取一个已在豁免集内的能力 —— 不变量同样由构造成立。代价:organization_admin 持 setup.access,会因此通过写门,而它今天被拒;且这会与 ADR-0066 D1 把 manage_metadata 定为授权能力的定位相抵。
• (C) 什么都不做 —— 承认不变量只靠 admin_full_access 上的共现成立,把它写成文档而非不变量。代价:任何手写权限集只要拆开这两者,两个方向上都会立刻分离(卡里事实 1 与事实 2 各是一个方向的实例)。

⛔ 本席不在三者中代选。#6603 的机制已两次裁定,且由其第二条理由(关掉「任何已认证会话都能覆盖 schema」这个既有洞)独立成立 —— 本卡不动摇它,只记录「裁决的陈述理由」与「合入的代码所强制的东西」之间的这道缝。

---

Generated by Claude Code