fix(plugin-sharing): require platform authority to delete a platform-global sharing rule (#7795) (#8156)

`deleteRule` on a row with `organization_id = null` now refuses a caller who
holds only the org-scoped `manage_sharing` capability, with a
`PERMISSION_DENIED` the REST layer answers as 403. `manage_platform_settings`,
the built-in `platform_admin` position and system contexts stay permitted.

Such a rule belongs to no organization and its criteria query runs unscoped, so
the delete purged every tenant's `sys_record_share` grants under it — a
cross-tenant destructive act authorized by a `scope: 'org'` capability. Both
measurements the ruling rests on were re-verified against this build first: the
boot seeder revives the rule under a NEW id on the next restart (a revocation
wearing removal's clothes), and an org admin's `active: false` creates a second
org-stamped row while the shared rule keeps running (the safe lever refused,
the destructive one permitted).

403 and not 404 is deliberate: #7760 opened listing, reading and evaluating
seeded rules to org admins on purpose, and all three are untouched here, so a
404 would contradict a read the same caller can perform one call earlier.

Maintainer ruling 2026-08-12 (方向 B), quoted verbatim in the guard's docblock.


Claude-Session: https://claude.ai/code/session_01PEVB6w7D7uCszR9Mw1BL73

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

Author: os-zhuang

.changeset/platform-global-sharing-rule-delete-gate.md

@@ -0,0 +1,26 @@
+---
+'@objectstack/plugin-sharing': patch
+---
+
+Refuse deletion of a platform-global sharing rule to org-scoped callers (#7795)
+
+`SharingRuleService.deleteRule` now requires **platform** authority to delete a
+sharing rule whose `organization_id` is `null` — a row seeded from declared
+metadata that belongs to no organization. A caller holding only the org-scoped
+`manage_sharing` capability is refused with `PERMISSION_DENIED`, which the REST
+layer answers as **403**; the `manage_platform_settings` capability, the
+built-in `platform_admin` position, and system contexts are all still permitted.
+
+Why: such a rule's criteria query runs unscoped, so deleting it purged **every**
+tenant's `sys_record_share` grants under it — a cross-tenant destructive act
+authorized by a capability declared `scope: 'org'`. Two measured facts made it
+worse: the boot seeder re-creates the rule on the next restart under a *new* id,
+so the delete was a revocation wearing removal's clothes rather than a removal;
+and the safe lever was unavailable while the destructive one was not — an org
+admin's `active: false` creates a second, org-stamped row and leaves the shared
+rule running, so deletion was the only lever an org admin had over it.
+
+Deliberately **403, not 404**: the row is intentionally visible — listing,
+reading and evaluating platform-global rules stay open to org admins, exactly as
+shipped — so answering "no such rule" would contradict a read the same caller
+can perform one call earlier. Nothing on the read/evaluate surface changes.

packages/plugins/plugin-sharing/src/sharing-rule-service.ts

@@ -12,6 +12,10 @@ import type {
 // has declared for every one of these context parameters since #6523 (the
 // #6206 ruling: no per-site subset contracts).
 import type { ExecutionContext } from '@objectstack/spec/kernel';
+// [#7795] The built-in platform-operator position (ADR-0068 D2) — one of the
+// two spellings of platform authority the ruling names; see
+// {@link SharingRuleService.assertCanDeletePlatformGlobalRule}.
+import { BUILTIN_IDENTITY_PLATFORM_ADMIN } from '@objectstack/spec/identity';
 import type { SharingEngine } from './sharing-service.js';
 import type { SharingService } from './sharing-service.js';
 import { normalizeAccessLevel, normalizeStoredAccessLevel } from './access-level.js';
@@ -116,6 +120,111 @@ export class SharingRuleService implements ISharingRuleService {
     );
   }
 
+  /**
+   * [#7795] DELETING a platform-global (`organization_id = null`) rule requires
+   * PLATFORM authority. Org-scoped `manage_sharing` does not authorize it.
+   *
+   * Maintainer ruling, 2026-08-12 (方向 B), quoted verbatim and untranslated:
+   *
+   * > **裁定:方向 B —— read/evaluate 保持开放,delete 需要平台级权限。**
+   * >
+   * > - `deleteRule` 对 `organization_id = null` 的行,要求调用者持有平台级权限
+   * >   (`manage_platform_settings` 或 `platform_admin` 位置);仅持 org 级
+   * >   `manage_sharing` 者拒绝。
+   * > - 错误面用 **403 `PERMISSION_DENIED`**,不是 404 —— 该行是有意可见的,
+   * >   404 会撒谎。
+   * > - #7760 开放的能力(列出、查看、评估种子规则)全部保持不动。
+   *
+   * ## Why only DELETE, and only this row class
+   *
+   * `manage_sharing` is declared `scope: 'org'` in the spec's capability
+   * registry, but a null-org rule belongs to no organization: its criteria
+   * query runs unscoped under {@link SYSTEM_CTX}, so {@link deleteRule}'s
+   * grant purge revokes EVERY tenant's `sys_record_share` rows, not just the
+   * caller's. That is the one act on this surface an org-level capability
+   * should not reach, and the two measurements the ruling rests on say why —
+   * both re-verified against this build before the guard was written:
+   *
+   * 1. **The delete is a revocation wearing removal's clothes.**
+   *    `bootstrapDeclaredSharingRules` re-seeds declared rules on every boot,
+   *    and {@link defineRule}'s existence lookup under a null org is `{name}` —
+   *    which matches nothing once the row is deleted, so the insert branch
+   *    mints a fresh `uid('srule')`. Measured: the rule returns after a
+   *    restart under a DIFFERENT id, with its grants re-materialised. The
+   *    profile of an outage, not of an administrative change.
+   * 2. **The safe lever is unavailable while the destructive one is not.**
+   *    An org admin cannot deactivate this row: `defineRule`'s existence
+   *    lookup is deliberately strict (`{name, organization_id: orgId}`, held
+   *    that way by #7676 so one org cannot upsert over a row other orgs read),
+   *    so `active: false` from an org admin creates a SECOND, org-stamped row
+   *    and leaves the shared one running. Measured: two rows, the null-org one
+   *    still `active: true`. Scoped + reversible refused, cross-tenant +
+   *    irreversible-until-reboot permitted — the inverse of the safe
+   *    arrangement, and closing the destructive lever is the structural fix.
+   *
+   * ## Two spellings of platform authority, and why BOTH are accepted
+   *
+   * They are not synonyms — they are two independent channels by which the
+   * SAME underlying grant (an unscoped `admin_full_access`) reaches an
+   * `ExecutionContext`:
+   *
+   * - `manage_platform_settings` — a `scope: 'platform'` CAPABILITY, arriving
+   *   on `context.systemPermissions`. `admin_full_access` carries it;
+   *   `organization_admin` deliberately withholds it (it gets only
+   *   `manage_org_users` / `setup.access` / `setup.write`), which is exactly
+   *   what makes it a discriminator between a platform operator and a tenant
+   *   admin — the same reasoning plugin-security's
+   *   `PLATFORM_ADMIN_ONLY_CAPABILITIES` probe encodes.
+   * - `platform_admin` — a built-in POSITION (ADR-0068 D2), arriving on
+   *   `context.positions`, DERIVED by the shared resolver from the unscoped
+   *   `admin_full_access` user grant (never a stored boolean).
+   *
+   * A context built by the shared authz resolver carries both. A HAND-BUILT
+   * context — the population ADR-0096 D3 is still eliminating, and which
+   * plugin-security's probe comment names the sharing service as part of —
+   * may carry only one. Accepting either is therefore the fail-safe reading of
+   * a ruling that names both, and refusing on the absence of both cannot
+   * silently over-refuse a genuine platform operator.
+   *
+   * ## The error surface is 403 `PERMISSION_DENIED`, deliberately not 404
+   *
+   * The row is DELIBERATELY visible: #7760 opened listing, reading and
+   * evaluating seeded rules to org admins on purpose, and this guard leaves
+   * all three untouched. A 404 here would be the platform lying about a row
+   * the caller could list and read one call earlier. The message prefix is
+   * what `rest-server.ts`'s sharing-rule `handleError` maps to HTTP 403 +
+   * `{code: 'PERMISSION_DENIED'}`, which is also the pairing the spec's own
+   * `HttpStatusErrorCodeMap[403]` records. ⛔ Do not "harden" this into a 404
+   * or a silent no-op — both re-open the lie this shape exists to avoid.
+   *
+   * Placed AFTER {@link getRule} resolves, so a row the caller cannot see at
+   * all keeps its existing silent-no-op behaviour rather than gaining a new
+   * refusal that would disclose the row's existence.
+   *
+   * ⚠️ Recorded consequence, accepted by the ruling: with delete closed, an org
+   * admin has NO lever at all over a platform-global rule. The ruling
+   * explicitly declines to pre-build a per-org suppression mechanism
+   * (「⛔ 不做 D」) absent measured demand — do not add one here.
+   */
+  private assertCanDeletePlatformGlobalRule(row: SharingRuleRow, context: ExecutionContext): void {
+    // Only the platform-global class is gated — an org's own rows are
+    // untouched, and so is every read verb.
+    if (row.organization_id != null) return;
+    // Boot seeding, hooks, backfills and the plugin machinery, as everywhere else.
+    if (context?.isSystem) return;
+    const caps = Array.isArray(context?.systemPermissions) ? context.systemPermissions : [];
+    if (caps.includes('manage_platform_settings')) return;
+    const positions = Array.isArray(context?.positions) ? context.positions : [];
+    if (positions.includes(BUILTIN_IDENTITY_PLATFORM_ADMIN)) return;
+    throw new Error(
+      'PERMISSION_DENIED: deleting a platform-global sharing rule requires platform authority — ' +
+        'the manage_platform_settings capability or the platform_admin position. Org-scoped ' +
+        'manage_sharing does not authorize it, because this rule belongs to no organization and ' +
+        'deleting it revokes every tenant’s grants under it (#7795). It remains listable, ' +
+        'readable and evaluable.',
+    );
+  }
+
   async defineRule(input: DefineSharingRuleInput, context: ExecutionContext): Promise<SharingRuleRow> {
     this.assertCanManageRules(context);
     if (!input.name) throw new Error('VALIDATION_FAILED: name is required');
@@ -336,6 +445,9 @@ export class SharingRuleService implements ISharingRuleService {
     this.assertCanManageRules(context); // [ADR-0111 D6]
     const row = await this.getRule(idOrName, context);
     if (!row) return;
+    // [#7795] A platform-global row is visible to an org admin by design
+    // (#7760) but is NOT theirs to destroy — 403, never 404.
+    this.assertCanDeletePlatformGlobalRule(row, context);
     // Drop materialised grants first so we don't orphan them.
     //
     // [#4434] This used to be a predicate-shaped `engine.delete` on