fix(plugin-sharing): a manage_sharing holder with no active organization no longer reads every tenant's sharing rules (#8158)

[os-zhuang]

Fixes#8158

SharingRuleService decided its admin read scope on the absence of an organization id, not on system-ness:

if(!orgId)returnwhere;// unscoped — every tenant's rows

That unfiltered branch exists for the system context (boot seeding, the reconcile hooks, the backfills), but it was reached on capability rather than system-ness, and the ADR-0111 D6 gate admits any caller holding the org-scopedmanage_sharing capability. Three sites shared the shape — adminOrgScope, getRule and findRuleRowByName — so an authenticated, non-system caller with neither organizationId nor tenantId read every organization's rules, resolved any of them by id or by name, and could evaluate them, which reconciles sys_record_share grants: a cross-tenant write.

Step 1 — reachability, measured through the real login path

The card filed its own gap ("whether a real deployment can hand an authenticated manage_sharing holder a session with no activeOrganizationId is not measured here"). It is measured now, over HTTP, in packages/qa/dogfood/test/sharing-rule-org-less-caller.dogfood.test.ts:

• better-auth sign-up + sign-in mint the session; ADR-0081 D1's session.create.before hook is the thing that would stamp an active organization and declines, because the user holds no sys_member row (the test asserts the stored sys_session row carries none);

• the user holds an org-scoped manage_sharing grant anyway — a sys_user_permission_set row is independent of membership, and resolveUserAuthzGrants keeps an org-scoped grant when there is no active org to compare it against;

• GET /api/v1/sharing/rules as that session, on a fixture with two organizations, answered HTTP 200 on the pre-fix build with:

  ["rule_8158_tenant_a@org_8158_a", "rule_8158_tenant_b@org_8158_b",
  "share_high_value_red_projects_with_managers@null",
  "share_new_inquiries_with_field_ops@null",
  "share_open_tasks_with_manager@null",
  "share_red_projects_with_execs@null"]

  Both tenants' rules, to a caller whose only grant was scoped to tenant A. Reachability: yes.

The shape is ordinary, not contrived: a multi-organization deployment (whose membership reconciler binds nobody — ADR-0093 D1 no-target-org), an invite-only deployment, a user removed from their organization, or an SSO JIT user pending placement all produce it.

The fix

The three sites now take the execution context instead of a bare org id, so "system" and "no organization" can no longer be the same input, and assertCanManageRules refuses an authenticated caller with no resolvable organization: PERMISSION_DENIED, mapped to HTTP 403 by the route's existing error mapping.

Refuse rather than answer empty. Both are fail-closed; the difference is what the caller is told. An empty list is the #7676 shape — {data: []} over rules that exist and are actively granting access — which reads as "this deployment has no sharing rules". manage_sharing is declared scope: 'org': with no organization there is no scope in which it grants anything, so the honest answer is a refusal naming the missing organization.

Two classes keep the unfiltered read, deliberately — system contexts (isSystem), and platform operators (manage_platform_settings or the platform_admin position), whose cross-tenant read is what the platform-only Setup sharing pages are and who are exactly the caller a single-tenant deployment has before its default organization is bootstrapped. The card's own reading: "a platform operator hitting this path is harmless".

Tests

• packages/plugins/plugin-sharing/src/sharing-rule.test.ts — a new [#8158] block: two organizations with a rule each plus the platform-global seed, so it cannot pass on a single-tenant fixture; refusals for list / get-by-id / get-by-name / evaluate / delete / define, each paired with the row it used to leak; the grant table asserted unchanged after the refused evaluate; and the permitted side pinned — system context still reads and still SEEDS, both platform-authority spellings still read unfiltered, each org-bound admin sees exactly its own organization plus the platform-global row, and the tenantId spelling (what resolveAuthzContext actually stamps) resolves.
• packages/qa/dogfood/test/sharing-rule-org-less-caller.dogfood.test.ts — the HTTP-level proof above.

Ablation (prediction written first, then measured): restoring the three if (!orgId) branches turned exactly the 8 predicted unit refusals and the 7 predicted dogfood refusals red, and left every system / platform / org-bound pin green.

Docs — the new refusal is enumerated where refusals are enumerated

A second commit documents it on both pages a reader would reach, following #8217's precedent (the runtime refusing more than the page says is the enforced-but-undocumented inverse of a declared-but-unenforced gap):

• content/docs/permissions/sharing-rules.mdx — the ADR-0111 D6 "Rule administration" section, which is where the rule surface's 403 PERMISSION_DENIED already lives: the capability alone is not enough, an active organization is required, and system contexts + platform operators are deliberately unaffected.
• content/docs/kernel/runtime-services/sharing-service.mdx — the "Typical Errors" list docs(sharing-service): name the federated phantom-anchor case in the SHARING_NOT_ENABLED list (#8119) #8217 corrected twenty minutes before this PR. The new condition rides on the existing PERMISSION_DENIED bullet, explicitly scoped to ISharingRuleService (declared in the same canonical source) and cross-linked to the page above. That page's version was taken from current main so docs(sharing-service): name the federated phantom-anchor case in the SHARING_NOT_ENABLED list (#8119) #8217's line is preserved.

Related: #7795 (this card's origin), #7761, #7676, #5852. Adjacent, deliberately not unified here: #8208 is the same "authenticated session with no active organization" state falling closed in a different subsystem.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 12, 2026 10:04pm

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-sharing.

7 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/kernel/runtime-services/examples.mdx(via @objectstack/plugin-sharing)
• content/docs/kernel/runtime-services/sharing-service.mdx(via @objectstack/plugin-sharing)
• content/docs/kernel/services-checklist.mdx(via @objectstack/plugin-sharing)
• content/docs/permissions/authorization.mdx(via packages/plugins/plugin-sharing)
• content/docs/permissions/permissions-matrix.mdx(via packages/plugins/plugin-sharing)
• content/docs/plugins/packages.mdx(via @objectstack/plugin-sharing)
• content/docs/protocol/objectql/security.mdx(via packages/plugins/plugin-sharing)

⛔ 1 release-owned page(s) also reference the affected code. These are read-only:

• content/docs/releases/implementation-status.mdx(via @objectstack/plugin-sharing)

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.