fix(plugin-security): row-scope sys_invitation read to its addressee; keep the full ledger with owner/admin (#8095) (#8242)

* fix(plugin-security): row-scope sys_invitation read to the addressee (#8095)

A plain org member could read every sys_invitation row of the org through the
data API — other invitees' email addresses, the role each was about to be
granted, the inviter and the expiry — because the BETTER_AUTH_MANAGED_OBJECTS
blanket grants allowRead on every managed identity table while neither
member_default nor viewer_readonly declared a row policy for this object, and
an object with no applicable policy compiles to a null Layer 1.

member_default and viewer_readonly each gain sys_invitation_self
(select, email == current_user.email). The full ledger stays with
owner/admin via organization_admin's sys_invitation_org. The object-level read
bit is deliberately left open so the addressee still reads their OWN row — the
accept/reject row actions are gated on record.email == ctx.user.email, so
closing the object would break acceptance while looking like the same fix.

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

* fix(plugin-security): keep the org-admin invitation read whole on the wall-less posture (#8095)

The member-side row scope reaches org admins too — member_default resolves for
every authenticated principal via the everyone anchor — and on the DEFAULT
single posture neither mechanism that normally keeps an admin whole is present:
ADR-0105 D4 withholds the viewAllRecords short-circuit from a wall-less
deployment (organization_admin_no_bypass), and ADR-0105 D3 strips
sys_invitation_org as a platform tenant policy when org isolation is inactive.

Measured on a stock boot with only the member-side scope: the org OWNER read
zero invitations. organization_admin now states the admission in its own right
as sys_invitation_org_admin, positions-domained to org_owner/org_admin with a
predicate carrying no tenant token for the strip to key on. The domain only
ever widens, so a principal it does not match keeps the addressee scope and
fails closed.

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/sys-invitation-row-scope.md

@@ -0,0 +1,74 @@
+---
+"@objectstack/plugin-security": patch
+---
+
+fix(plugin-security): a plain member can no longer read the organization's whole invitation ledger (#8095)
+
+**Security — narrowing.** Any authenticated `member` of an organization could
+read **every** `sys_invitation` row of that organization through the data API:
+each invitee's email address, the role they were about to be granted, who
+invited them, and the expiry. Measured live: `GET /api/v1/data/sys_invitation`
+as a plain member returned `200` with the same rows the org **owner** sees.
+
+The grant was declared, not accidental. `sys_invitation` is in
+`BETTER_AUTH_MANAGED_OBJECTS`, whose blanket `denyWritesOnManagedObjects()`
+entry sets `allowRead: true` on every managed identity table for
+`member_default` and `viewer_readonly` — reads permitted, "subject to the rest
+of the RLS chain". For this object there was no rest of the chain: neither set
+declared a row-level policy for `sys_invitation`, and an object with no
+applicable policy compiles to a null business-RLS filter, i.e. no row scope at
+all. `sys_member` is a staff directory and reads org-wide on purpose; a pending
+invitation is administrative *intent* about people who are not members and never
+consented to a directory listing — and *who is about to become an admin* is
+enough for targeted social engineering.
+
+**What changed.** `member_default` and `viewer_readonly` each gain one
+row-level policy, `sys_invitation_self` (`select`,
+`email == current_user.email`), and `organization_admin` (with the wall-less
+`organization_admin_no_bypass` variant derived from it) gains
+`sys_invitation_org_admin` — the org-administration side of the same ledger,
+scoped by `positions` to `org_owner` / `org_admin`.
+
+The second policy is not decoration. `member_default` resolves for **every**
+authenticated principal (the `everyone` anchor), so the addressee scope reaches
+org admins too, and on the **default** `single` posture neither mechanism that
+normally keeps an admin whole is present: the wildcard
+`viewAllRecords` short-circuit is withheld from a wall-less deployment
+(ADR-0105 D4), and `sys_invitation_org` is stripped as a platform tenant policy
+when org isolation is inactive (ADR-0105 D3). Measured on a stock boot with only
+the member-side scope in place, the org **owner** read zero invitations — the
+Invitations page would have gone blank for the one persona entitled to it.
+`sys_invitation_org_admin` states the admission on the axis that survives both,
+carrying no tenant token for the strip to key on; the organization boundary
+remains Layer 0's, which AND-composes ahead of it, so its widest reach is the
+admin's own organization — exactly what `sys_invitation_org` already declared.
+
+**The invitee still sees their own invitation**, and that half is not
+incidental: the recipient-side row actions on `sys_invitation`
+(`accept_invitation` / `reject_invitation`) are gated on
+`record.email == ctx.user.email`, so an addressee who cannot read their row
+cannot act on it. The object-level read bit is therefore deliberately left open
+and the narrowing done at the row level — closing the object would have broken
+acceptance while looking like the same fix.
+
+**Not covered by the ruling, and therefore unchanged here:** a
+`delegated_admin` normalizes to neither `org_owner` nor `org_admin`, so that
+role now reads only its own row through the data API even though it may issue
+invitations. Filed separately rather than decided in this PR.
+
+**Unaffected.** Every better-auth organization endpoint
+(`invite-member`, `accept-invitation`, `reject-invitation`,
+`cancel-invitation`, `list-invitations`, `list-user-invitations`,
+`get-invitation`) reads and writes `sys_invitation` through the identity
+adapter under a system context, so the invitation lifecycle and the console's
+accept page — which use those endpoints, not the data API — behave exactly as
+before. Owners and admins are unchanged, in both the wall-enforcing
+(`organization_admin`) and wall-less (`organization_admin_no_bypass`)
+variants. Platform admins are unchanged.
+
+**You may notice** that a principal who is neither owner nor admin no longer
+sees other people's invitations on a generic `sys_invitation` grid — including
+the Setup app's Invitations page and the Organization record's Invitations tab
+if a non-admin reaches them. That is the fix, not a regression. A deployment
+that genuinely wants a wider invitation read should declare it on an
+application permission set rather than rely on the managed-object baseline.

packages/plugins/plugin-security/src/objects/default-permission-sets.test.ts

@@ -94,3 +94,74 @@ describe('default permission sets carry the managed denies (static baseline)', (
     expect(Object.keys(admin.objects)).toEqual(['*']);
   });
 });
+
+/**
+ * [#8095] The `sys_invitation` row scope — a DELETION TRIPWIRE, not the proof.
+ *
+ * The proof that the narrowing works lives over HTTP, in
+ * `packages/qa/dogfood/test/invitation-ledger-row-scope.dogfood.test.ts`: an
+ * assertion whose expectation and reality both come from this module cannot
+ * fail, so nothing here is evidence that a member is actually narrowed. What
+ * this block does buy is the one thing the HTTP fixture cannot — it names the
+ * predicate and the sets it must appear in, so removing a carve-out (or adding
+ * a managed object to `BETTER_AUTH_MANAGED_OBJECTS` and assuming the blanket
+ * read is safe for it) fails HERE, in the file being edited, instead of in a
+ * suite the author may not run.
+ *
+ * The predicate is written out rather than imported for the same reason.
+ */
+describe('sys_invitation is row-scoped to its addressee (#8095)', () => {
+  const SELF_PREDICATE = 'email == current_user.email';
+
+  // eslint-disable-next-line @typescript-eslint/no-explicit-any
+  const policiesFor = (setName: string, object: string): any[] =>
+    (setByName(setName)?.rowLevelSecurity ?? []).filter((p: any) => p.object === object);
+
+  it.each(['member_default', 'viewer_readonly'])(
+    '%s scopes sys_invitation to the addressee — the blanket managed read is NOT the whole story',
+    (setName) => {
+      // The object-level read bit stays open: it is what makes the invitee's OWN
+      // row reachable, and closing it would break the accept flow rather than
+      // narrow it. The narrowing is the row predicate.
+      expect(setByName(setName).objects.sys_invitation.allowRead).toBe(true);
+
+      const scoped = policiesFor(setName, 'sys_invitation');
+      expect(scoped.map((p) => p.name)).toEqual(['sys_invitation_self']);
+      expect(scoped[0].using).toBe(SELF_PREDICATE);
+      // Read the operation off THIS policy. The same-named carve-outs across
+      // these sets do not all agree (`sys_api_key_self` is spelled three times
+      // at two different operations), so a sibling's value is not evidence.
+      expect(scoped[0].operation).toBe('select');
+      expect(scoped[0].enabled).not.toBe(false);
+    },
+  );
+
+  it('organization_admin keeps the ORG-wide ledger — the ruling narrowed members, not admins', () => {
+    // The other half of the ruling, and the half that is easy to get wrong:
+    // `member_default` resolves for admins too, so the member-side scope reaches
+    // them, and the two mechanisms that look like they already protect an admin
+    // are both absent on the DEFAULT `single` posture — the `viewAllRecords`
+    // short-circuit is withheld from `organization_admin_no_bypass` (ADR-0105
+    // D4), and `sys_invitation_org` is stripped as a platform tenant policy when
+    // org isolation is inactive (ADR-0105 D3). Only `sys_invitation_org_admin`
+    // survives both, which is why it must be present on BOTH variants.
+    for (const setName of ['organization_admin', 'organization_admin_no_bypass']) {
+      const scoped = policiesFor(setName, 'sys_invitation');
+      expect(scoped.map((p) => p.name).sort(), `${setName} sys_invitation policies`).toEqual([
+        'sys_invitation_org',
+        'sys_invitation_org_admin',
+      ]);
+
+      const admission = scoped.find((p) => p.name === 'sys_invitation_org_admin');
+      // No tenant token — that is what keeps the strip from taking it.
+      expect(admission.using).not.toContain('current_user.organization_id');
+      expect(admission.using).toBe('id != null');
+      // Domained to the org-administration identities, so it can only WIDEN.
+      // A principal it does not match keeps the addressee scope and fails
+      // closed; putting the domain on the narrowing instead would make "no
+      // matching position" mean "no policy" — i.e. no row filter at all.
+      expect(admission.positions.sort()).toEqual(['org_admin', 'org_owner']);
+      expect(admission.operation).toBe('select');
+    }
+  });
+});

packages/plugins/plugin-security/src/objects/default-permission-sets.ts

@@ -1,7 +1,12 @@
 // Copyright (c) 2025 ObjectStack. Licensed under the Apache-2.0 license.
 
 import { PermissionSetSchema, type PermissionSet } from '@objectstack/spec/security';
-import { ORGANIZATION_ADMIN, ORGANIZATION_ADMIN_NO_BYPASS } from '@objectstack/spec';
+import {
+  ORGANIZATION_ADMIN,
+  ORGANIZATION_ADMIN_NO_BYPASS,
+  BUILTIN_IDENTITY_ORG_ADMIN,
+  BUILTIN_IDENTITY_ORG_OWNER,
+} from '@objectstack/spec';
 import {
   MCP_AGENT_PERMISSION_SET_READ,
   MCP_AGENT_PERMISSION_SET_WRITE,
@@ -23,6 +28,18 @@ import {
  * permission sets keep their `*` wildcard so they can rescue data
  * directly when needed.
  *
+ * ⚠️ "Subject to the rest of the RLS chain" is the load-bearing half, and it is
+ * a BLANKET grant — read this list as 22 objects whose object-level read bit is
+ * open, each narrowed (or not) by whatever `rowLevelSecurity` its holder set
+ * declares for it. An object named here with NO `_self` / `_org` policy in
+ * `member_default` is org-wide readable by every authenticated member. That is
+ * intended for the staff-directory shapes (`sys_member`, `sys_user` via
+ * `sys_user_org_members`) and was NOT intended for `sys_invitation`
+ * (maintainer ruling 2026-08-12) — see `sys_invitation_self` below. Do not
+ * "fix" a future instance of this class by editing the blanket: dropping
+ * `allowRead` here retires the read on all 22 at once, and it would take the
+ * invitee's own row with it. The per-object row scope is the narrow instrument.
+ *
  * This is the COMPILE-TIME BASELINE. At `kernel:ready` it is unioned with the
  * live registry by `applyManagedWriteDenies` (see `managed-object-write-denies.ts`),
  * which injects a deny entry for every registered `managedBy: 'better-auth'`
@@ -302,6 +319,55 @@ const baseDefaultPermissionSets: PermissionSet[] = [
         operation: 'select',
         using: 'organization_id == current_user.organization_id',
       },
+      // [#8095] The org-admin half of the invitation narrowing, and the reason
+      // it needs a SECOND policy rather than leaning on the one above.
+      //
+      // `member_default` now row-scopes `sys_invitation` to the addressee, and
+      // that set resolves for EVERY authenticated principal (the `everyone`
+      // anchor) — org owners and admins included. Policies OR-combine, so an
+      // admin is only unnarrowed while some policy of theirs still admits the
+      // rest of the ledger. Two mechanisms were supposed to do that, and in the
+      // DEFAULT posture neither does:
+      //   - the wildcard `viewAllRecords` short-circuit skips Layer 1 whole —
+      //     but ADR-0105 D4 withholds those bits from a wall-less deployment,
+      //     which is where `organization_admin_no_bypass` comes from;
+      //   - `sys_invitation_org` above is a PLATFORM TENANT POLICY, and
+      //     `collectRLSPolicies` strips those when org isolation is inactive
+      //     (ADR-0105 D3) — correctly, since `current_user.organization_id`
+      //     means nothing without a wall.
+      // Measured on a stock `single`-posture boot: with only the member-side
+      // scope in place, the org OWNER read ZERO invitations. The Invitations
+      // page would have gone blank for the one persona entitled to it, on the
+      // default posture, as a side effect of a member-side fix.
+      //
+      // So the admission is stated in its own right, on the axis that survives
+      // both mechanisms: `positions` (ADR-0090 P2's applicability domain — the
+      // same lever `owner_only_writes` uses to keep a members-only restriction
+      // off admins), with a predicate carrying no tenant token for the strip to
+      // key on. `id != null` is every row of this object, said plainly: the
+      // organization boundary is NOT this policy's job — Layer 0 is the tenant
+      // wall (ADR-0095 D1) and AND-composes ahead of it, so the widest this can
+      // ever reach is the admin's own organization, which is exactly what
+      // `sys_invitation_org` already declares. It is the same grant, spelled so
+      // a wall-less deployment keeps it.
+      //
+      // Why a `positions` DOMAIN rather than dropping the member-side scope's
+      // reach: the domain here only ever WIDENS, so a principal it does not
+      // match keeps the addressee scope and fails closed. Putting the domain on
+      // the narrowing instead would invert that — anyone outside the listed
+      // positions (an org-less session, a role that normalizes to neither name)
+      // would match no policy at all, and no policy means NO row filter, which
+      // is precisely the wide read #8095 is about.
+      //
+      // `delegated_admin` is deliberately absent: the ruling narrows the ledger
+      // to owner/admin, and that role normalizes to neither name.
+      {
+        name: 'sys_invitation_org_admin',
+        object: 'sys_invitation',
+        operation: 'select',
+        using: 'id != null',
+        positions: [BUILTIN_IDENTITY_ORG_OWNER, BUILTIN_IDENTITY_ORG_ADMIN],
+      },
       {
         name: 'sys_team_org',
         object: 'sys_team',
@@ -597,6 +663,63 @@ const baseDefaultPermissionSets: PermissionSet[] = [
         operation: 'select',
         using: 'user_id == current_user.id',
       },
+      // [#8095] The invitation ledger is ADMINISTRATIVE INTENT, not a staff
+      // directory — row-scoped to the addressee.
+      //
+      // `sys_invitation` is in BETTER_AUTH_MANAGED_OBJECTS, so the blanket above
+      // grants read on it; this set declared NO policy for the object, and an
+      // object with no applicable policy compiles to a null Layer 1 — i.e. no
+      // row filter at all (`RLSCompiler.compileFilter` returns null on an empty
+      // applicable set). Measured live: a plain `member` of an org got
+      // `200, total: 2` on `GET /api/v1/data/sys_invitation` — byte-identical to
+      // what the org OWNER sees, including other people's email addresses, the
+      // role each is about to be granted, the inviter and the expiry. Pending
+      // invitees are not members and never consented to a directory listing, and
+      // "who is about to become an admin" is the wrong thing to broadcast.
+      //
+      // Maintainer ruling (2026-08-12): narrow the read to owner/admin, PLUS a
+      // row-scope carve-out so an invitee still sees THEIR OWN invitation. Both
+      // halves are load-bearing and this policy is both of them at once:
+      //   - NARROWING — for a rank-and-file member this is now the only
+      //     applicable policy, so the readable set is exactly `{their own row}`;
+      //   - CARVE-OUT — the accept flow's surfaces are record-scoped
+      //     (`sys_invitation`'s `accept_invitation` / `reject_invitation` row
+      //     actions declare `visible: record.email == ctx.user.email`), so an
+      //     invitee who cannot READ their row cannot act on it. Narrowing
+      //     without this predicate would break acceptance while looking like a
+      //     permissions fix.
+      // ⚠️ This set resolves for EVERY authenticated principal (the `everyone`
+      // anchor), so the predicate binds org owners and admins too — and the
+      // arrival of a first policy on an object that had none is a NARROWING for
+      // whoever it reaches, not a no-op. Keeping the admin whole therefore takes
+      // an explicit admission on their side: `sys_invitation_org_admin` in
+      // `organization_admin` (which the `_no_bypass` variant inherits). Read its
+      // comment before touching either one — the two mechanisms that look like
+      // they already cover the admin (the `viewAllRecords` short-circuit and
+      // `sys_invitation_org`) are BOTH absent on the default `single` posture,
+      // and with only this policy in place the org owner measurably read zero
+      // invitations.
+      //
+      // `email` (not `user_id`): an invitation predates the account it invites,
+      // so the addressee is identified by address. `current_user.email` is the
+      // auth-enforced, unique-by-construction identity `RLSUserContext` exposes
+      // for exactly this (the display `name` is deliberately not exposed). When
+      // it cannot be resolved the policy compiles to nothing and the single
+      // applicable policy yields `RLS_DENY_FILTER` — zero rows, fail-closed.
+      //
+      // `select` (not `all`), matching `sys_inbox_message_self` above: every
+      // write on this table is denied at the object layer by the managed-object
+      // block, refused again by the ADR-0092 D2 identity write guard, and
+      // answered 405 by `apiMethods: ['get', 'list']` before either. The #7665
+      // derive-from-select rule additionally lends this predicate to the write
+      // classes should a write bit ever be granted, so `all` would buy nothing
+      // and would overstate what the policy is for.
+      {
+        name: 'sys_invitation_self',
+        object: 'sys_invitation',
+        operation: 'select',
+        using: 'email == current_user.email',
+      },
     ],
   }),
   PermissionSetSchema.parse({
@@ -698,6 +821,24 @@ const baseDefaultPermissionSets: PermissionSet[] = [
         operation: 'select',
         using: 'user_id == current_user.id',
       },
+      // [#8095] Same row scope as `member_default`'s `sys_invitation_self`, and
+      // it must be repeated here rather than inherited: this set is resolved
+      // INSTEAD of the member baseline for a read-only principal, and its `'*'`
+      // wildcard read is if anything wider — carrying no `viewAllRecords`, it
+      // does NOT take the Layer 1 short-circuit, so without a policy of its own
+      // a viewer would read the whole org's invitation ledger that a member can
+      // no longer see. `select` here matches this set's own convention (every
+      // carve-out above is `select`; `viewer_readonly` grants no write bit at
+      // all) and happens to agree with `member_default`'s — which is NOT a rule
+      // to generalise from: the `sys_api_key_self` carve-out is spelled three
+      // times across these sets at two different `operation` values. Read the
+      // `operation` on each policy; never infer it from a same-named sibling.
+      {
+        name: 'sys_invitation_self',
+        object: 'sys_invitation',
+        operation: 'select',
+        using: 'email == current_user.email',
+      },
     ],
   }),
 

packages/plugins/plugin-security/src/objects/rbac-objects.test.ts

@@ -106,6 +106,13 @@ describe('default permission sets', () => {
       // `_self` shape for the same reason: no `organization_id`, so Layer 0 is
       // inert and these policies are the row scoping for their read grants.
       'sys_inbox_message_self',
+      // [#8095] The invitation ledger's row scope. Keyed on `email`, not
+      // `user_id`, because an invitation predates the account it invites — the
+      // addressee is identified by address. Its object DOES carry
+      // `organization_id`, so unlike the two above this is not "Layer 0 is
+      // inert here": Layer 0 was engaged and correctly org-scoped, and the org
+      // is precisely the audience the row must be hidden from.
+      'sys_invitation_self',
       'sys_notification_receipt_self',
       'sys_oauth_access_token_self',
       'sys_oauth_application_self',