Security-adjacent. The observed failure is fail-closed (403s, no data exposure), but the mechanism — one app's baseline silently displacing the platform baseline for the everyone anchor — is a permission-composition defect, and the same displacement decides what an app's members do keep.
Symptom
A fresh member (purpose-signed-up, no positions beyond the implicit ones) is served the whole Account app and can use none of it:
- All 10 Account-app nav ids are served to the member.
- 7/7 of the objects backing those entries answer 403 on read.
So every built-in Account destination is a dead end for that persona, while the nav still advertises all of them.
Expected: either the platform baseline still applies to members of an app that declares its own baseline (so the built-in Account destinations keep working), or the entries whose objects the caller cannot read are pruned from the served nav. Neither happens.
Root cause
The report locates the chain, at this level:
-
The showcase declares its own baseline set and binds it to the everyone anchor. Boot log, verbatim:
[security] baseline set bound to everyone anchor (ADR-0090 D5)
-
That binding replaces rather than composes with the platform member_default. Measured breadth: platform member_default grants 23 objects — including all the Account ones — while showcase_member_default grants 7.
-
Therefore this is not a showcase-specific fixture problem: every built-in Account destination dies for members on any app that declares a baseline.
-
The second, unprunable half: the Account nav entries are gated with requiresObject, not requiredPermissions, so the nav server has no signal with which to prune an entry whose backing object the caller cannot read. The entry is served regardless of the 403 that follows.
The report does not name the exact code site of the replace-vs-compose behaviour — it locates it at the ADR-0090 D5 everyone-anchor binding. The presumed home is the baseline/permission-set assembly in packages/plugins/plugin-security; confirm the site before fixing rather than assuming it from this card.
Reproduction
- Boot the showcase app; confirm the boot log line
[security] baseline set bound to everyone anchor (ADR-0090 D5).
- Sign up a fresh member and sign in.
- Read the served nav for the Account app — all 10 nav ids are present.
- For each of the 7 objects backing those entries,
GET /api/v1/data/<object> as that member — all 7 answer 403.
Reproduced 2× with two independent member sessions.
Related
Source
Extracted from the QA run #7514 (framework a86db17, console 09987b68).
Security-adjacent. The observed failure is fail-closed (403s, no data exposure), but the mechanism — one app's baseline silently displacing the platform baseline for the
everyoneanchor — is a permission-composition defect, and the same displacement decides what an app's members do keep.Symptom
A fresh member (purpose-signed-up, no positions beyond the implicit ones) is served the whole Account app and can use none of it:
So every built-in Account destination is a dead end for that persona, while the nav still advertises all of them.
Expected: either the platform baseline still applies to members of an app that declares its own baseline (so the built-in Account destinations keep working), or the entries whose objects the caller cannot read are pruned from the served nav. Neither happens.
Root cause
The report locates the chain, at this level:
The showcase declares its own baseline set and binds it to the
everyoneanchor. Boot log, verbatim:That binding replaces rather than composes with the platform
member_default. Measured breadth: platformmember_defaultgrants 23 objects — including all the Account ones — whileshowcase_member_defaultgrants 7.Therefore this is not a showcase-specific fixture problem: every built-in Account destination dies for members on any app that declares a baseline.
The second, unprunable half: the Account nav entries are gated with
requiresObject, notrequiredPermissions, so the nav server has no signal with which to prune an entry whose backing object the caller cannot read. The entry is served regardless of the 403 that follows.The report does not name the exact code site of the replace-vs-compose behaviour — it locates it at the ADR-0090 D5
everyone-anchor binding. The presumed home is the baseline/permission-set assembly inpackages/plugins/plugin-security; confirm the site before fixing rather than assuming it from this card.Reproduction
[security] baseline set bound to everyone anchor (ADR-0090 D5).GET /api/v1/data/<object>as that member — all 7 answer 403.Reproduced 2× with two independent member sessions.
Related
sys_jwksis API-disabled and arequiredPermissionsgate cannot prune it #7544 is the sibling half of the same "a nav entry cannot be pruned" gap: there the gate isrequiredPermissionsand the blocker isenable.apiEnabled:false; here the gate isrequiresObjectand the blocker is the baseline replacement. A prune rule that covers only one gate vocabulary will leave the other dead.sys_inbox_message. That is a different cause (an absolute gap in the platform baseline) and its write-up describesmember_defaultas much narrower than the 23 objects measured here. Measure the current baseline contents rather than trusting either number — the two runs are on different framework commits.member_default's*wildcard object grant (C/R/E) union-merges into every org member — app-side explicit-allow object gates are erased on three axes #5491 (closed) deliberately narrowedmember_defaultfrom a*wildcard to explicit-allow. This card does not dispute that narrowing; it disputes replacement vs composition when an app binds its own baseline to the same anchor.Source
Extracted from the QA run #7514 (framework a86db17, console 09987b68).