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

* fix(plugin-sharing): scope sharing-rule administration to the caller's organization (#8158)

`SharingRuleService` took its unfiltered admin read branch on the ABSENCE of an
organization id rather than on system-ness, so an authenticated, non-system
caller holding the org-scoped `manage_sharing` capability with no active
organization read every tenant's sharing rules, resolved any of them by id or
name, and could evaluate them — a cross-tenant write, since evaluation
reconciles `sys_record_share` grants.

The three sites that shared the `if (!orgId)` shape (`adminOrgScope`,
`getRule`, `findRuleRowByName`) now take the execution context, and an
authenticated caller with no resolvable organization is refused with
PERMISSION_DENIED (403). System contexts (boot seeding, hooks, backfills) and
platform operators (`manage_platform_settings` / the `platform_admin`
position) keep the unfiltered read unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PEVB6w7D7uCszR9Mw1BL73

* docs(sharing): name the missing-organization refusal on both sharing pages (#8158)

The "Typical Errors" list on `services.sharing` enumerates the exact conditions
behind each status, and the ADR-0111 D6 section of the sharing-rules page is
where a reader of the rule surface looks. This PR adds a refusal to that
surface — an authenticated `manage_sharing` holder whose session resolves no
active organization now gets 403 PERMISSION_DENIED on every verb — so both
pages say so, including which two callers (system contexts, platform
operators) are deliberately unaffected.

Same reasoning as #8217: the runtime refusing more than the page says is the
enforced-but-undocumented inverse of a declared-but-unenforced gap.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PEVB6w7D7uCszR9Mw1BL73

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-zhuang

.changeset/sharing-rule-org-less-caller-scope.md

@@ -0,0 +1,50 @@
+---
+"@objectstack/plugin-sharing": patch
+---
+
+security(plugin-sharing): a `manage_sharing` holder with no ACTIVE organization no longer reads every tenant's sharing rules (#8158)
+
+`SharingRuleService` decided its admin read scope on the **absence of an
+organization id**, not on system-ness:
+
+```ts
+if (!orgId) return where;   // unscoped — every tenant's rows
+```
+
+That unfiltered branch exists for the system context — boot seeding, the
+reconcile hooks, the backfills — which legitimately reads across tenants. But
+it was reached by any caller whose context happened to carry no organization,
+and the ADR-0111 D6 gate admits any caller holding the **org-scoped**
+`manage_sharing` capability. So an authenticated, non-system caller arriving
+with neither `organizationId` nor `tenantId` received the system read scope:
+`listRules` returned **every organization's** rules, `getRule` resolved any of
+them by id or by name, and `evaluateRule` reached those rows too — a
+cross-tenant **write**, since it reconciles `sys_record_share` grants.
+
+**That session is reachable in a real deployment**, measured end to end over
+HTTP rather than inferred: a permission-set grant is independent of
+organization membership, and an org-scoped grant still resolves when the caller
+has no active organization to compare it against. A user holding
+`manage_sharing` with no `sys_member` row — a multi-organization deployment
+(whose membership reconciler binds nobody), an `invite-only` deployment, a user
+removed from their organization, an SSO JIT user pending placement — signs in,
+carries the capability, and carries no tenant.
+
+**The fix** distinguishes "system context" from "no organization id" at the
+decision point instead of conflating them: `adminOrgScope`, `getRule` and
+`findRuleRowByName` (three sites, one shape) now take the execution context,
+and an authenticated caller with no resolvable organization is **refused** with
+`PERMISSION_DENIED` (HTTP 403) naming the missing organization. A refusal
+rather than an empty list, because `manage_sharing` is declared `scope: 'org'`:
+with no organization there is no scope in which it grants anything, and an
+empty answer over rules that exist and are actively granting access reads as
+"this deployment has no sharing rules".
+
+**Unchanged**, and covered by tests: system contexts keep the unfiltered read
+and the unfiltered seed (boot seeding is untouched); **platform operators**
+(`manage_platform_settings`, or the `platform_admin` position) keep it too,
+with or without an active organization — that is what the platform-only Setup
+sharing pages are, and a single-tenant deployment before its default
+organization is bootstrapped has exactly that caller; and an org-bound admin
+still sees its own organization's rules plus the platform-global ones, exactly
+as #7676 / #7761 left it.

content/docs/kernel/runtime-services/sharing-service.mdx

@@ -57,7 +57,7 @@ mask AND-ed with object CRUD, not a fourth `access_level`.
 
 - `FORBIDDEN` (403) — a write denied by the `canEdit` gate. Thrown by the sharing engine middleware; `canEdit` itself returns `false` rather than throwing.
 - `VALIDATION_FAILED` (400) — `grant`/`revoke` called without a required field (`object`, `recordId`, `recipientId`, or `shareId`), or `grant` with a non-`user` `recipientType` (only `user` rows are enforced by the gates; group/position recipients are delivered via sharing rules).
-- `PERMISSION_DENIED` (403) — the caller does not hold `canManageShares` on the record (ADR-0111 D1).
+- `PERMISSION_DENIED` (403) — the caller does not hold `canManageShares` on the record (ADR-0111 D1). On the sharing-**rule** surface (`ISharingRuleService`, declared in the same canonical source — `listRules` / `getRule` / `defineRule` / `deleteRule` / `evaluateRule`) the same code carries a second condition: the caller holds `manage_sharing` but their session resolves **no active organization**, and an org-scoped capability with no organization has no tenant whose rules it authorizes. System contexts and platform operators (`manage_platform_settings`, or the `platform_admin` position) are unaffected — see [Rule administration](/docs/permissions/sharing-rules).
 - `NOT_FOUND` (404) — the record is missing **or not visible to the caller** (indistinguishable by design), or a `revoke` share id does not exist / does not belong to the `scope` record.
 - `CONFLICT` (409) — `revoke` on a rule-materialised share (`source != 'manual'`); the next rule reconciliation would silently re-grant it. Deactivate or edit the sharing rule instead.
 - `SHARING_NOT_ENABLED` (422) — `grant` on an object the sharing gates never consult (public sharing model, no `owner_id` field, a bypass object, `controlled_by_parent`, or a **federated** object whose `owner_id` is the platform's injected anchor rather than a real remote column — the platform provisions no storage for a federated object, so the gates read that column off a table that has not got it and can never admit).

content/docs/permissions/sharing-rules.mdx

@@ -161,6 +161,22 @@ covered; an unauthorized call fails with `403 PERMISSION_DENIED`. Boot
 seeding, lifecycle hooks, and backfills run as system context and are
 unaffected.
 
+**…and an organization to be scoped by.** `manage_sharing` is declared
+`scope: 'org'`, so the capability alone is not enough: the caller's session
+must also resolve an **active organization**, which is what scopes every rule
+read to "this organization ∪ the platform-global rows". A session that carries
+none — a user who has not selected an organization, or whose active
+organization was cleared — is refused with the same `403 PERMISSION_DENIED`,
+naming the missing organization rather than answering with an empty list.
+Answering unscoped would hand that caller **every** organization's rules, and
+`evaluate` would reconcile grants across all of them (objectstack#8158).
+Two callers are deliberately unaffected, because neither is an org-scoped
+principal: **system** contexts, and **platform operators** — a holder of
+`manage_platform_settings` or of the built-in `platform_admin` position
+administers rules across the deployment whether or not an organization is
+selected, which is also what a single-tenant deployment looks like before its
+default organization is bootstrapped (ADR-0081 D1).
+
 ### Switching a rule off withdraws the access it granted
 
 A sharing rule's grants are **materialized** — evaluating a rule writes real