fix(plugin-security): require by-id write targets to be within the caller's readable set under select-only RLS (#7792)

* fix(plugin-security): require by-id write targets to be within the caller's readable set under select-only RLS

An object whose row narrowing is authored as `operation: 'select'` rules only
had an open by-id write path. A contributor could PATCH records they could not
read — 200, values persisted — on the master object AND on a
`controlled_by_parent` detail, while the read side correctly hid the same rows
(GET 404, absent from list). Measured live on the stock showcase by QA run
#7637, on three objects, twice each.

The by-id write pre-image gate, the controlled_by_parent master check and the
bulk write filter all compose the RLS filter for the WRITE operation. With no
update-scope policy applicable to the caller that filter compiled to a null
Layer 1, and all three row gates became a no-op at once; OWD
`public_read_write` then let `resolveSharingCanEdit` admit the write, and the
detail derived its access from that same permissive master verdict.

An empty write-class policy collection now derives its scope from the caller's
SELECT narrowing, at the single decision site in `computeLayeredRlsFilter` —
the same policies, compiled by the same compiler, that the read path enforces.

Deliberately not derived: when any write-class policy applies (an authored
predicate or the in-domain platform ownership floor), so app-authored write
wideners keep deciding alone and the #7401 / #6736 directions are preserved
exactly; for `insert`, which has no pre-image to be visible; and when the
caller holds the read-side superuser bypass on a posture-permitting object,
whose readable set is unbounded — the mirror of the read path's own Layer 1
short-circuit, so a derived write scope can never be narrower than the read
scope it comes from.

Fixes #7665

Co-Authored-By: Claude <noreply@anthropic.com>

* docs(permissions): record that a `select` policy also bounds writes when no write-class policy applies

The "Choosing `operation`" paragraph described `select` as narrowing reads and
the write classes as guarding "the matching write" — the exact mental model
that produced #7665, and now an understatement of what the platform enforces.

States the derivation and its three boundaries: it applies only when no
write-class policy applies to the caller (an authored write predicate keeps
deciding its class alone), never for `insert`, and never for a caller holding
the read-side superuser bypass. Adds a pointer from the `operation` property
row.

Co-Authored-By: Claude <noreply@anthropic.com>

---------

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

Author: os-help

.changeset/select-only-rls-by-id-write-visibility.md

@@ -0,0 +1,33 @@
+---
+"@objectstack/plugin-security": patch
+---
+
+fix(plugin-security): a by-id write target must be inside the caller's readable set when only select-scope RLS is authored
+
+An object whose row narrowing is authored as `operation: 'select'` rules only had an
+**open by-id write path**. A low-privilege user could `PATCH` records they could not
+read — 200, values persisted — on the object itself and on a `controlled_by_parent`
+detail, while the read side correctly hid the same rows (404 on GET, absent from list).
+
+The cause was a single missing scope. The by-id write pre-image gate, the
+controlled_by_parent master check and the bulk write filter all compose the RLS filter
+for the **write** operation. With no update-scope policy applicable to the caller,
+that filter compiled to nothing and every one of those row gates became a no-op at
+once; an open sharing model (`public_read_write`) then admitted the write. Deriving the
+detail's access from the same permissive master verdict spread it to details as well.
+
+An empty write-class policy collection now **derives its scope from the caller's
+`select` narrowing** — the same policies, compiled by the same compiler, that the read
+path enforces. "You cannot mutate what you cannot see" holds by construction on all
+three gates, and the explain engine reports the same narrowing for `update`/`delete`
+that it reports for `read` instead of "No RLS policy applies".
+
+Migration-visible change: on an object narrowed by select-only RLS, a by-id or bulk
+`update`/`delete` of a row **outside the caller's readable set** is now refused
+(`PERMISSION_DENIED`, 403) where it previously succeeded. Reads, inserts, and any
+object that **does** author an update- or delete-scope policy are unaffected — where a
+write-class predicate exists it keeps deciding alone, so app-authored write wideners
+behave exactly as before. Callers holding a read-side superuser bypass
+(`viewAllRecords` on a posture-permitting object) are not newly narrowed. An app that
+relied on the previous behaviour should author an explicit `operation: 'update'` policy
+expressing the wider write scope it intends.

content/docs/permissions/rls.mdx

@@ -58,7 +58,7 @@ export const ContributorAccess = definePermissionSet({
 | `name` | `string` | snake_case identifier |
 | `label` | `string` | Human-readable name |
 | `object` | `string` | Target object — or `'*'` to apply to every object |
-| `operation` | `'select' \| 'insert' \| 'update' \| 'delete' \| 'all'` | Which operation the policy guards |
+| `operation` | `'select' \| 'insert' \| 'update' \| 'delete' \| 'all'` | Which operation the policy guards. A `select` policy also bounds writes when no write-class policy applies — see below |
 | `using` | `string` | Predicate for rows the user may **see / act on** (compiled into the query filter) |
 | `check` | `string` | Predicate rows must satisfy **after a write**. Omit it and `using` is reused |
 | `positions` | `string[]` | Which positions the policy applies to. Omit = everyone |
@@ -71,6 +71,17 @@ At least one of `using` / `check` is required.
 everything. Internally `find` / `findOne` / `count` / `aggregate` all map to
 `select`.
 
+**`select` also bounds writes when nothing else does.** A write target must be
+inside the caller's **readable** set, so when **no** write-class policy applies
+to a caller on an object, the `update` / `delete` scope is derived from that
+caller's `select` policies — a record they cannot read is one they cannot
+modify, by id or in bulk. Authoring a write-class policy switches the
+derivation off for that class: an authored `update` predicate then decides
+`update` alone and widens exactly as written. Nothing is derived for `insert`
+(there is no pre-existing row to be visible), and a caller holding the
+read-side superuser bypass (`viewAllRecords` on a private or platform-global
+object) is not narrowed, because their readable set is already unbounded.
+
 ## The expression grammar
 
 RLS predicates are **canonical CEL**, lowered into a query filter by the shared

packages/plugins/plugin-security/src/security-plugin.ts

@@ -1426,9 +1426,13 @@ export class SecurityPlugin implements Plugin {
       // engine with `{ id } AND <writeFilter>`; a `find` does not re-enter this
       // block, so there is no recursion, and read-side RLS/tenant scoping
       // compose naturally. A `null` result means the row is either gone or
-      // RLS-hidden → deny. When `computeRlsFilter` returns `null` (no policy
-      // applies — e.g. an admin set with no RLS, or `modifyAllRecords`) the
-      // check is skipped and behaviour is unchanged.
+      // RLS-hidden → deny. When `computeRlsFilter` returns `null` the check
+      // is skipped — but since #7665 that is a far smaller class than "no
+      // WRITE policy applies": an empty write-class collection now derives
+      // its scope from the caller's SELECT narrowing inside
+      // `computeLayeredRlsFilter`, so the skip happens only when the caller's
+      // READABLE set is unbounded too (an admin set with no RLS at all, or a
+      // posture-permitting superuser bypass).
       //
       // [#5492] The filter is composed BY PROVENANCE. Two of the policies that
       // can land in it are the platform's OWN ownership floor
@@ -1586,8 +1590,12 @@ export class SecurityPlugin implements Plugin {
 
       // 2.8. ADR-0055 — controlled-by-parent WRITE: a detail write (insert/update/
       // delete) requires edit access to its master. The detail itself carries no
-      // authored RLS, so the #1994 pre-image check above is a no-op for it; this
-      // closes the by-id write path by checking the master instead.
+      // authored RLS (nothing to derive from either, #7665), so the #1994
+      // pre-image check above is a no-op for it; this closes the by-id write
+      // path by checking the master instead — and the master's own write
+      // filter, since #7665, derives from its SELECT narrowing when no
+      // write-class policy applies, so a select-only master gates its details
+      // by visibility too.
       if (
         ['insert', 'update', 'delete', 'transfer', 'restore', 'purge'].includes(opCtx.operation) &&
         permissionSets.length > 0 &&
@@ -3925,7 +3933,54 @@ export class SecurityPlugin implements Plugin {
     // longer skip the tenant wall (that is Layer 0's own exemption, below).
     let layer1: Record<string, unknown> | null = null;
     if (!(posturePermits && superuserBypass)) {
-      const collected = this.collectRLSPolicies(permissionSets, object, operation, (context?.positions ?? []) as string[]);
+      let collected = this.collectRLSPolicies(permissionSets, object, operation, (context?.positions ?? []) as string[]);
+      // [#7665] The write-visibility floor: a write target must be inside the
+      // caller's READABLE set. When NO policy of the write class applies to
+      // this (principal, object, operation) — nothing authored for the class,
+      // and the platform ownership floor outside its `positions` domain — the
+      // write class used to compile to a null Layer 1, and every write-side
+      // row gate composed from it became a no-op at once: the by-id pre-image
+      // gate (step 2.7), the controlled_by_parent master check, and the bulk
+      // write AST injection. QA #7637 measured the result on the stock
+      // showcase (select-only narrowing, `contributor` position, OWD
+      // `public_read_write`): a contributor PATCHed by id records they could
+      // not read — on the master AND on a controlled_by_parent detail — while
+      // the read side correctly hid them.
+      //
+      // So an empty write-class collection now DERIVES the write scope from
+      // the caller's SELECT narrowing — the same policies, compiled by the
+      // same compiler, that the read path enforces. "You cannot mutate what
+      // you cannot see" then holds by construction, and the explain engine
+      // reports the same narrowing for update/delete that it reports for
+      // read, instead of "No RLS policy applies".
+      //
+      // Deliberately NOT derived:
+      //   - when ANY write-class policy applies (an authored predicate, or
+      //     the in-domain platform floor): those paths keep their exact
+      //     semantics, including every widening direction #7401 / #6736
+      //     track — #7665 criterion 5 (derive ONLY when no update-scope
+      //     predicate exists). `checkAuthoredRowWrite` is additionally
+      //     protected by its own authored-set pre-check, so a derived scope
+      //     can never masquerade as an authored admission (#5493 / #7281);
+      //   - for `insert` — there is no pre-existing row to be visible (a
+      //     controlled_by_parent detail INSERT is still gated through its
+      //     master's derived scope by step 2.8);
+      //   - when the caller holds the read-side superuser bypass on a
+      //     posture-permitting object — their readable set is unbounded, so
+      //     the readability requirement imposes nothing. This is the mirror
+      //     of the read path's own Layer-1 short-circuit above, so the
+      //     derived write scope can never be NARROWER than the read scope it
+      //     is derived from.
+      if (
+        collected.length === 0 &&
+        (operation === 'update' || operation === 'delete') &&
+        !(
+          posturePermits &&
+          this.permissionEvaluator.hasSuperuserReadBypass(object, permissionSets, { isPrivate: meta.isPrivate })
+        )
+      ) {
+        collected = this.collectRLSPolicies(permissionSets, object, 'select', (context?.positions ?? []) as string[]);
+      }
       // [#5492] Provenance composition: the caller (the by-id write pre-image
       // gate) has already asked the declared write authority — `ISharingService`
       // — and received a positive `allow`. Its answer REPLACES the platform's own