@rebasepro/common 0.17.0 → 0.17.1-canary.gdc3e9e4

package/dist/util/internal-tables.d.ts

@@ -58,7 +58,10 @@ export declare const REBASE_USER_ROLE = "rebase_user";
  *
  * Deliberately NOT including `users`: the auth user table is also a collection,
  * with `securityRules`, RLS enabled and policies applied. Users read their own
- * row through it — revoking there would break sign-in.
+ * row through it — revoking there would break sign-in. `revokeInternalTableSql`
+ * now skips any table with RLS enabled, so that exception is enforced rather
+ * than merely remembered — and so is the same hazard for every other name here,
+ * any of which a project may legitimately use for a collection of its own.
  *
  * `atlas_schema_revisions` is Atlas's migration ledger, which lands in `rebase`
  * because `db migrate apply` passes `--revisions-schema rebase`.
@@ -69,8 +72,16 @@ export declare const REBASE_USER_ROLE = "rebase_user";
  * list is what the boot-time sweep in `ensureAppRole` iterates, and the sweep
  * is the only thing that can repair an already-granted table. A table revoked
  * at creation but missing here is therefore permanently stranded on any
- * database that predates its revoke — which is exactly what happened to
- * `jobs`, added here after a scan of a pre-0.14 database found it.
+ * database that predates its revoke.
+ *
+ * These names are unqualified, and the boot-time sweep applies them to every
+ * schema a project uses — so an entry here is a claim on that name in `public`
+ * as much as in `rebase`. `jobs` is Rebase's queue at `rebase.jobs` AND a
+ * perfectly ordinary collection name, and revoking `public.jobs` from a project
+ * that owns it leaves every read failing 42501 with correct policies applied
+ * and nothing in the RLS logs to explain it. The `relrowsecurity` guard in
+ * `revokeInternalTableSql` is what makes a common noun safe here — it is not a
+ * licence to claim more of them.
  */
 export declare const REBASE_INTERNAL_TABLES: readonly string[];
 /**
@@ -86,6 +97,25 @@ export declare const REBASE_INTERNAL_TABLES: readonly string[];
  *  - the table may not exist yet — `cron_logs` never appears in a project with
  *    no cron jobs — and `to_regclass` returning NULL has to be tolerated too.
  *
+ * The third guard is the one that decides whether the *right* table is being
+ * revoked. The names in {@link REBASE_INTERNAL_TABLES} are unqualified, and the
+ * boot-time sweep in `ensureAppRole` applies all of them to every schema a
+ * project uses — including the schema its own collections live in. A project is
+ * free to call a collection `jobs`, `branches` or `api_keys`, and when it does,
+ * the sweep was revoking `rebase_user`'s DML on the project's table on every
+ * single boot. That is not a subtle degradation: the collection's whole API
+ * answers 500 `permission denied for table …` from then on, which is what
+ * happened to a public job board whose vacancies live in `public.jobs`.
+ *
+ * `relrowsecurity` separates the two cleanly, and it is the same fact this
+ * module already relies on. Framework-internal tables carry no RLS — that is the
+ * premise stated at the top of this file, and the reason a revoke is needed at
+ * all. Every collection table has it enabled, because that is how Rebase
+ * enforces `securityRules`. So "RLS is off" is exactly "this is not somebody's
+ * collection", and the guard also subsumes the hand-carved `users` exception:
+ * the auth user table is a collection, has RLS, and would now be skipped on its
+ * own merits rather than by being kept off a list.
+ *
  * One command, so it is safe on handles that speak the extended query protocol
  * and reject multi-statement strings.
  */

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@rebasepro/common",
   "type": "module",
-  "version": "0.17.0",
+  "version": "0.17.1-canary.gdc3e9e4",
   "description": "Rebase shared core — collection registry, data driver adapter and fluent query builder. No React dependency.",
   "funding": {
     "url": "https://github.com/sponsors/rebaseco"
@@ -40,8 +40,8 @@
   "dependencies": {
     "fast-equals": "6.0.2",
     "json-logic-js": "^2.0.5",
-    "@rebasepro/types": "0.17.0",
-    "@rebasepro/utils": "0.17.0"
+    "@rebasepro/types": "0.17.1-canary.gdc3e9e4",
+    "@rebasepro/utils": "0.17.1-canary.gdc3e9e4"
   },
   "devDependencies": {
     "@jest/globals": "^30.4.1",

package/src/util/internal-tables.test.ts

@@ -96,6 +96,18 @@ describe("internal table access", () => {
             expect(revokeInternalTableSql("rebase", "cron_logs")).toContain("to_regclass");
         });
 
+        it("skips a table with RLS enabled, because that is somebody's collection", () => {
+            // The names in the list are unqualified and the boot sweep applies
+            // them to every project schema, so `public.jobs` — a job board's
+            // vacancies — was being revoked on every boot by the entry meant for
+            // `rebase.jobs`, the background queue. RLS is what tells them apart:
+            // collections have it, framework tables do not.
+            const sql = revokeInternalTableSql("public", "jobs");
+
+            expect(sql).toContain("relrowsecurity");
+            expect(sql).toMatch(/NOT \(SELECT relrowsecurity FROM pg_class WHERE oid = to_regclass\('"public"\."jobs"'\)\)/);
+        });
+
         it("is a single statement, for handles that reject multi-statement strings", () => {
             // The semicolons inside the block are PL/pgSQL's, not the protocol's:
             // what matters is that the whole string is one dollar-quoted DO,

package/src/util/internal-tables.ts

@@ -60,7 +60,10 @@ export const REBASE_USER_ROLE = "rebase_user";
  *
  * Deliberately NOT including `users`: the auth user table is also a collection,
  * with `securityRules`, RLS enabled and policies applied. Users read their own
- * row through it — revoking there would break sign-in.
+ * row through it — revoking there would break sign-in. `revokeInternalTableSql`
+ * now skips any table with RLS enabled, so that exception is enforced rather
+ * than merely remembered — and so is the same hazard for every other name here,
+ * any of which a project may legitimately use for a collection of its own.
  *
  * `atlas_schema_revisions` is Atlas's migration ledger, which lands in `rebase`
  * because `db migrate apply` passes `--revisions-schema rebase`.
@@ -71,8 +74,16 @@ export const REBASE_USER_ROLE = "rebase_user";
  * list is what the boot-time sweep in `ensureAppRole` iterates, and the sweep
  * is the only thing that can repair an already-granted table. A table revoked
  * at creation but missing here is therefore permanently stranded on any
- * database that predates its revoke — which is exactly what happened to
- * `jobs`, added here after a scan of a pre-0.14 database found it.
+ * database that predates its revoke.
+ *
+ * These names are unqualified, and the boot-time sweep applies them to every
+ * schema a project uses — so an entry here is a claim on that name in `public`
+ * as much as in `rebase`. `jobs` is Rebase's queue at `rebase.jobs` AND a
+ * perfectly ordinary collection name, and revoking `public.jobs` from a project
+ * that owns it leaves every read failing 42501 with correct policies applied
+ * and nothing in the RLS logs to explain it. The `relrowsecurity` guard in
+ * `revokeInternalTableSql` is what makes a common noun safe here — it is not a
+ * licence to claim more of them.
  */
 export const REBASE_INTERNAL_TABLES: readonly string[] = [
     // auth
@@ -120,6 +131,25 @@ const SAFE_IDENTIFIER = /^[A-Za-z_][A-Za-z0-9_$]*$/;
  *  - the table may not exist yet — `cron_logs` never appears in a project with
  *    no cron jobs — and `to_regclass` returning NULL has to be tolerated too.
  *
+ * The third guard is the one that decides whether the *right* table is being
+ * revoked. The names in {@link REBASE_INTERNAL_TABLES} are unqualified, and the
+ * boot-time sweep in `ensureAppRole` applies all of them to every schema a
+ * project uses — including the schema its own collections live in. A project is
+ * free to call a collection `jobs`, `branches` or `api_keys`, and when it does,
+ * the sweep was revoking `rebase_user`'s DML on the project's table on every
+ * single boot. That is not a subtle degradation: the collection's whole API
+ * answers 500 `permission denied for table …` from then on, which is what
+ * happened to a public job board whose vacancies live in `public.jobs`.
+ *
+ * `relrowsecurity` separates the two cleanly, and it is the same fact this
+ * module already relies on. Framework-internal tables carry no RLS — that is the
+ * premise stated at the top of this file, and the reason a revoke is needed at
+ * all. Every collection table has it enabled, because that is how Rebase
+ * enforces `securityRules`. So "RLS is off" is exactly "this is not somebody's
+ * collection", and the guard also subsumes the hand-carved `users` exception:
+ * the auth user table is a collection, has RLS, and would now be skipped on its
+ * own merits rather than by being kept off a list.
+ *
  * One command, so it is safe on handles that speak the extended query protocol
  * and reject multi-statement strings.
  */
@@ -135,7 +165,8 @@ export function revokeInternalTableSql(schema: string, table: string): string {
         DO $rebase_revoke$
         BEGIN
             IF EXISTS (SELECT 1 FROM pg_roles WHERE rolname = '${REBASE_USER_ROLE}')
-               AND to_regclass('${qualified}') IS NOT NULL THEN
+               AND to_regclass('${qualified}') IS NOT NULL
+               AND NOT (SELECT relrowsecurity FROM pg_class WHERE oid = to_regclass('${qualified}')) THEN
                 EXECUTE 'REVOKE ALL ON ${qualified} FROM ${REBASE_USER_ROLE}';
             END IF;
         END