Skip to content

member_default's removed wildcard is still live fact in a PUBLISHED customer skill and in plugin-security/README.md — the two sites outside #6964's named file face #7151

Description

@os-zhuang

Found while implementing #6964 (PR #7149), by sweeping the same two expired premises across their whole consumption radius rather than only the packages that card named. Filed unassigned and unlabeled — deliberately not pre-graded, for the same reason #6964's filer declined to pre-grade: one of these two is ordinary prose drift and the other is published customer-facing security guidance, and that difference is triage's call, not the filer's.

The two premises (identical to #6964)

Both re-measured on origin/main @ 3e8e669c0 against the real imported defaultPermissionSets: member_default.objects['*'] is undefined, and its rowLevelSecurity carries no tenant_isolation entry — only owner_only_writes / owner_only_deletes (update/delete) and the *_self per-object carve-outs.

#6964 named platform-objects, qa/dogfood and content/docs/permissions/index.mdx, and its dispatch drew that file face explicitly. These two sites are outside it and were not fixed by PR #7149.

1. skills/objectstack-data/SKILL.md — a PUBLISHED customer skill, both premises

This is the sharper of the two: not an internal comment but shipped guidance, and it does not merely mention the wildcard — it builds a recommendation on it.

:764 asserts premise (b) as current:

  • The default member_default ships a wildcard tenant_isolation RLS (organization_id == current_user.organization_id). Any row whose organization_id is null or absent (common for adapter-written rows that never get the tenant stamp) is denied — the list renders empty.

:781 asserts premise (a), inside a warning callout:

⚠️ Don't use either flag alone. tenancy.enabled:false by itself drops the wildcard RLS, and member_default's '*': allowRead then leaks every row to all authenticated users.

The recommended recipe itself (tenancy: { enabled: false } + requiredPermissions) is still correct, so this is not a wrong instruction — but every reason given for it has expired, and one of them names a leak that cannot happen. A reader who checks the stated hazard finds it absent and may drop half the recipe. The viewAllRecords sentence at :768 is also now imprecise in the same region: under ADR-0095 W2 the superuser bit alone no longer crosses the tenant wall at all — that takes a true PLATFORM_ADMIN (superuser bit and a platform-exclusive capability), which is a stricter rule than "posture-gated".

Note this file is a skills/ artifact, so it is in scope for the skill-frame gates; any fix should re-run check:skill-frame-sync / check:doc-authoring.

2. packages/plugins/plugin-security/README.md:51 — premise (b)

  • Service present → keeps the wildcard tenant_isolation RLS policy (organization_id = current_user.organization_id) shipped with the default member_default / viewer_readonly permission sets.
  • Service absent → strips those wildcard policies so single-tenant deployments aren't filtered to zero rows.

The described mechanism is the pre-ADR-0095 one. Tenant scope is now Layer 0, and it is inert under the single posture by construction (computeTenantLayer0Filter returns null when postureEnforcesWall is false) rather than by the org-scoping probe stripping policies. This is the plugin's own README describing its own retired behaviour.

Worth checking in the same pass whether viewer_readonly still ships such a policy — the sentence names it alongside member_default, and #6964 only ever measured member_default.

Verified correct — explicitly NOT part of this finding

These matched the same grep and were checked individually:

Why it stayed silent

Same reason #6842 and #6964 give, and the reason this keeps recurring: nothing mechanically relates "prose names set X as having shape Y" to what defaultPermissionSets actually ships. The #6958 pin closes that loop for two named surfaces only. If triage ever does want the pin to grow a repo-wide surface, these two files are the concrete argument for it — this is now the third filing in the same family.

Related: #6964 / PR #7149 (this issue's origin), #6842 / PR #6958, #6696 / PR #6846, #5491 / PR #6684 (cause (a)), ADR-0095 D1 (cause (b)), #6628 (the pin idiom).

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