@everystack/cli 0.4.55 → 0.4.56

package/src/cli/commands/security.ts

@@ -15,6 +15,7 @@ import fs from 'node:fs/promises';
 import path from 'node:path';
 import {
   audit,
+  schemaDescriptorsFromContract,
   parseFunctionsFromSql,
   parseViewsAndGrantsFromSql,
   type Waivers,
@@ -28,6 +29,7 @@ import {
   catalogFunctionToDescriptor,
   catalogRelationToDescriptor,
 } from '../security-catalog.js';
+import { SCHEMA_ACL_SQL, parseSchemaAcl } from '../authz-contract.js';
 import { resolveConfig, opsFunction } from '../config.js';
 import { invokeAction } from '../aws.js';
 import { step, success, fail, info, warn } from '../output.js';
@@ -116,11 +118,28 @@ export async function auditDeployedSql(
   step('Introspecting database catalog (functions + relations)...');
   const fnRows = await catalogQuery(region, opsFn, FUNCTIONS_SQL);
   const relRows = await catalogQuery(region, opsFn, RELATIONS_SQL);
+  // A10(ii) — the PRECONDITION leg. Unpinned SECDEF and owner-bypasses-RLS both describe the
+  // privileged CODE; neither says whether an attacker can plant something for it to resolve to.
+  // Only the catalog path can answer that, so the static path leaves `schemas` empty rather
+  // than report every schema as clean.
+  const aclRows = await catalogQuery(region, opsFn, SCHEMA_ACL_SQL);
 
   const functions: FunctionDescriptor[] = fnRows.map(catalogFunctionToDescriptor);
   const views: ViewDescriptor[] = relRows.map(catalogRelationToDescriptor);
-  info(`Catalog: ${functions.length} function(s), ${views.length} relation(s).`);
-  return audit(functions, views, waivers);
+  const schemaAcls: Record<string, Record<string, string[]>> = {};
+  for (const row of aclRows) {
+    schemaAcls[String(row.schema)] = parseSchemaAcl(row.acl == null ? '{}' : String(row.acl)) ?? {};
+  }
+  const schemas = schemaDescriptorsFromContract(
+    schemaAcls,
+    fnRows.map((r: any) => ({
+      name: `${r.schema}.${r.name}`,
+      securityDefiner: r.security_definer === true || r.security_definer === 't',
+      hasSearchPath: r.has_search_path === true || r.has_search_path === 't',
+    })),
+  );
+  info(`Catalog: ${functions.length} function(s), ${views.length} relation(s), ${schemas.length} schema(s).`);
+  return audit(functions, views, waivers, schemas);
 }
 
 async function catalogQuery(region: string, fn: string, sql: string): Promise<any[]> {
@@ -153,12 +172,14 @@ export function printReport(report: AuditReport, instrument: 'static' | 'catalog
   const reds = [
     ...report.functions.filter((f) => f.severity === 'red'),
     ...report.views.filter((v) => v.severity === 'red'),
+    ...report.schemas.filter((s) => s.severity === 'red'),
   ];
   const warns = [
     ...report.functions.filter((f) => f.severity === 'warn'),
     ...report.views.filter((v) => v.severity === 'warn'),
+    ...report.schemas.filter((s) => s.severity === 'warn'),
   ];
-  const waived = report.functions.filter((f) => f.waived);
+  const waived = [...report.functions.filter((f) => f.waived), ...report.schemas.filter((s) => s.waived)];
 
   if (reds.length > 0) {
     console.log('');

package/src/cli/db-build.ts

@@ -129,6 +129,19 @@ export async function buildIntoDatabase(
     for (const schema of [...new Set([...modelSchemas, ...derivedSchemas])].filter((s) => s && s !== 'public').sort()) {
       await runner(`CREATE SCHEMA IF NOT EXISTS "${schema}"`);
     }
+    // A10(i) — ASSERT the schema posture, do not inherit it.
+    //
+    // PG15 removed PUBLIC's CREATE on schema `public`; before that it was the default, and it
+    // still rides in with any pre-PG15 dump. So a database everystack BUILDS was hardened only
+    // by accident of the server version, while one it ADOPTS was not — and db:fingerprint
+    // reported MATCH across both. A security posture that depends on which major created the
+    // database is exactly the environmental dependence this class of defect is about.
+    //
+    // Safe here and ONLY here: db:build refuses a database that already holds objects, so there
+    // is nothing in `public` to strand. Bringing an ADOPTED database to this posture is a
+    // reviewable REVOKE the operator sees before it runs, never a silent side effect — some
+    // legacy apps do create objects in `public` at runtime.
+    await runner('REVOKE CREATE ON SCHEMA public FROM PUBLIC');
     const createdRoles = await ensureContractRoles(runner, models);
 
     // FUNCTIONS BEFORE STATE. An RLS policy's predicate is resolved when the policy is
@@ -170,12 +183,34 @@ export async function buildIntoDatabase(
         await runner('RESET check_function_bodies');
       }
     }
-    const run = await executeSync(runner, session, models, {
+    let run = await executeSync(runner, session, models, {
       declared: options.declared,
       sequences: options.sequences,
       actor: options.actor ?? 'db-build',
       gitRef: options.gitRef ?? null,
     });
+    // A12 — THE SECOND PASS, and it is inherent to building from nothing rather than a patch
+    // over one bug. `executeSync` is a single diff-and-verify: it reads the live authz contract,
+    // computes the delta, applies it. On a FROM-SCRATCH build some objects the authz layer must
+    // grant on do not exist at read time — most sharply the sequence behind a serial column,
+    // which our own CREATE TABLE makes moments later. So the first pass cannot see it, the
+    // sequence inheritance rule (A6) has nothing to grant on, and the build lands with a role
+    // that may INSERT into a table but cannot draw its sequence value.
+    //
+    // Caught by the round-trip oracle (B7), not by A6's own tests: the rule converges perfectly
+    // against an EXISTING database, which is what those tests exercise.
+    //
+    // Bounded at exactly one extra pass. The second read sees everything the first one created,
+    // so a third could only differ if the apply were non-convergent — and that is a real failure
+    // the `converged` bar must report, never something to loop away.
+    if (!run.converged) {
+      run = await executeSync(runner, session, models, {
+        declared: options.declared,
+        sequences: options.sequences,
+        actor: options.actor ?? 'db-build',
+        gitRef: options.gitRef ?? null,
+      });
+    }
     return {
       converged: run.converged,
       fingerprintMatch: run.fingerprintMatch,

package/src/cli/derived-apply.ts

@@ -106,19 +106,72 @@ export function ensureOrReplace(sql: string): string {
 const WITH_NO_DATA_RE = /WITH\s+NO\s+DATA\s*$/i;
 
 /**
- * An object's full creation SQL: the CREATE statement plus its attachments, in
- * source order. A matview whose source says `WITH NO DATA` gets a trailing
- * REFRESH: the reconciler dropped a populated matview to rebuild it, and
- * executing the source verbatim would leave it unpopulated — matching the
- * text but regressing the database. (Found by a consumer whose extracted
- * sources carry pg_dump's WITH NO DATA ordering.)
+ * How the applier enacts a declared owner. Chosen from the BUILDER, not from taste.
+ *
+ * `set-role` — run the CREATE as the owner. Works for any builder that can assume the role, and
+ * it is the only option for a non-superuser builder: PostgreSQL will not let it hand an object
+ * to somebody else. The cost is real, and it is borne by the role the feature exists to protect:
+ * the CREATE happens AS the owner, so the owner needs `CREATE` on the schema — and a
+ * deliberately-powerless operator role commonly has CREATE nowhere.
+ *
+ * `alter-owner` — create as the builder, then `ALTER … OWNER TO`. Available only to a SUPERUSER
+ * (or rds_superuser member), which needs neither membership in the owner nor CREATE for it, and
+ * can replace a function it does not own on the re-run. Measured on PG16.
+ *
+ * Getting this backwards is not cosmetic: forcing `set-role` on a superuser builder would demand
+ * a privilege expansion onto the very role that is supposed to hold none.
+ */
+export type OwnerApplyMode = 'set-role' | 'alter-owner';
+
+/**
+ * An object's full creation SQL: the CREATE statement plus its attachments, in source order. A
+ * matview whose source says `WITH NO DATA` gets a trailing REFRESH: the reconciler dropped a
+ * populated matview to rebuild it, and executing the source verbatim would leave it unpopulated
+ * — matching the text but regressing the database. (Found by a consumer whose extracted sources
+ * carry pg_dump's WITH NO DATA ordering.)
+ *
+ * A declared owner is enacted one of two ways; see {@link OwnerApplyMode} for which and why.
  */
-function objectSql(obj: SourceObject): string[] {
+function objectSql(obj: SourceObject, ownerMode: OwnerApplyMode = 'set-role'): string[] {
   const statements = [obj.sql, ...obj.attachments.map((a) => a.sql)];
   if (obj.kind === 'materialized view' && WITH_NO_DATA_RE.test(normalizeSql(obj.sql))) {
     statements.push(`REFRESH MATERIALIZED VIEW ${quoteQualified(obj.identity)}`);
   }
-  return statements;
+  if (!obj.owner) return statements;
+
+  if (ownerMode === 'alter-owner') {
+    // A superuser builder creates as itself and hands the object over. It needs no membership in
+    // the owner and no CREATE on the owner's behalf, so the owner role stays as powerless as it
+    // was designed to be — which is the whole point of naming it. The re-run is safe for the
+    // same reason: a superuser may CREATE OR REPLACE a function it does not own.
+    //
+    // The ALTER trails the attachments because a superuser can still make them either way, and
+    // "build it, then hand it over" is the order a reader expects.
+    return [...statements, `${ALTER_OWNER[obj.kind] ?? 'ALTER FUNCTION'} ${ownerTarget(obj)} OWNER TO ${obj.owner}`];
+  }
+
+  // Every other builder creates AS the owner. Measured on PG16: a non-superuser cannot give an
+  // object away, and once ownership has moved off the applying role the next `CREATE OR REPLACE`
+  // fails with "must be owner of function" — so the alter-after form would work exactly once and
+  // break every later reconcile. Creating under SET ROLE is correct by construction and stays
+  // correct on re-run.
+  //
+  // The attachments stay INSIDE the block: GRANT and COMMENT on a function require ownership, so
+  // once the function belongs to `owner` the applying role can no longer make them. RESET ROLE is
+  // last and unconditional — a leaked SET ROLE would silently re-own every object created after
+  // it. The role name is validated at declaration (defineFunction), never here.
+  return [`SET ROLE ${obj.owner}`, ...statements, 'RESET ROLE'];
+}
+
+const ALTER_OWNER: Record<string, string> = {
+  function: 'ALTER FUNCTION',
+  view: 'ALTER VIEW',
+  'materialized view': 'ALTER MATERIALIZED VIEW',
+};
+
+/** The `ALTER … OWNER TO` target. A function needs its argument types — the same rule as DROP. */
+function ownerTarget(obj: SourceObject): string {
+  return obj.kind === 'function' ? dropTarget('function', obj.identity) : quoteQualified(obj.identity);
 }
 
 /**
@@ -166,10 +219,22 @@ export function renderSetSearchPath(schemas: string[], local: boolean): string |
  *
  * `GRANT USAGE` rides along per schema (0a-bis mirrored), derived from the objects'
  * own grant attachments: a role granted SELECT on a matview in a non-public schema
- * cannot reach it without USAGE, so the object grant is dead without this. A PUBLIC
- * that appears only as explicitly-revoked gets nothing. Empty for all-public apps —
- * their apply stays byte-identical. Idempotent when the state layer already created
- * the schema (a model schema also carrying derived objects).
+ * cannot reach it without USAGE, so the object grant is dead without this. Empty for
+ * all-public apps — their apply stays byte-identical. Idempotent when the state layer
+ * already created the schema (a model schema also carrying derived objects).
+ *
+ * A13 — PUBLIC IS NEVER GRANTED SCHEMA USAGE HERE, and the reason is the distinction this
+ * codebase draws everywhere else: an ability is an intended audience, a privilege is a recorded
+ * fact. PostgreSQL grants every new function EXECUTE to PUBLIC, `db:pull` faithfully records
+ * that as `privileges: { PUBLIC: ['EXECUTE'] }` — and this pass used to read it as an audience
+ * and widen the SCHEMA to match. Caught by the round-trip oracle (B7): a schema whose original
+ * ACL gave PUBLIC nothing came back from a rebuild with `GRANT USAGE ON SCHEMA … TO PUBLIC`,
+ * turning an unreachable default grant into a reachable one. Recording a fact about one object
+ * must never widen a DIFFERENT object.
+ *
+ * The consequence is deliberate: a genuinely PUBLIC-callable function in a non-public schema
+ * needs schema USAGE, and that is now a decision someone DECLARES on the schema, not one this
+ * pass infers from a default nobody chose.
  */
 export function renderEnsureObjectSchemas(objects: SourceObject[]): string[] {
   const statements: string[] = [];
@@ -181,18 +246,184 @@ export function renderEnsureObjectSchemas(objects: SourceObject[]): string[] {
       if (o.schema !== schema) continue;
       const { grants } = parseGrantAttachments(o.attachments);
       for (const [role, privileges] of Object.entries(grants)) {
-        if (privileges.length > 0) roles.add(role);
+        // See A13 above: PUBLIC's presence here is a recorded default, never a declared
+        // audience, and widening the schema to match it is a real privilege escalation.
+        if (privileges.length > 0 && role.toUpperCase() !== 'PUBLIC') roles.add(role);
       }
     }
     if (roles.size > 0) {
-      const targets = [...roles].sort().map((r) => (r.toUpperCase() === 'PUBLIC' ? 'PUBLIC' : r)).join(', ');
-      statements.push(`GRANT USAGE ON SCHEMA ${quoteIdent(schema)} TO ${targets}`);
+      statements.push(`GRANT USAGE ON SCHEMA ${quoteIdent(schema)} TO ${[...roles].sort().join(', ')}`);
     }
   }
   return statements;
 }
 
-export function renderReconcileSql(plan: ReconcilePlan, source: SourceObject[]): RenderedReconcile {
+// ---------------------------------------------------------------------------
+// Declared-owner preflight — the refusal that beats a raw Postgres error.
+// ---------------------------------------------------------------------------
+
+/** One declared owner and every schema the batch will create an object of theirs in. */
+export interface OwnerRequirement {
+  owner: string;
+  schemas: string[];
+}
+
+/**
+ * The declared owners this batch will actually enact, and where.
+ *
+ * Scoped to CREATE and REPLACE, because those are the actions that run under `SET ROLE`. A
+ * baseline, a prune or an unchanged object never assumes anyone's identity, so demanding its
+ * owner be assumable would refuse work the batch was never going to attempt. On a from-scratch
+ * build every object is created, so this set is every declared owner anyway.
+ */
+export function ownerRequirements(plan: ReconcilePlan, source: SourceObject[]): OwnerRequirement[] {
+  const srcById = new Map(source.map((o) => [o.identity, o]));
+  const byOwner = new Map<string, Set<string>>();
+  for (const action of plan.actions) {
+    if (action.action !== 'create' && action.action !== 'replace') continue;
+    const obj = srcById.get(action.identity);
+    if (!obj?.owner) continue;
+    (byOwner.get(obj.owner) ?? byOwner.set(obj.owner, new Set()).get(obj.owner)!).add(obj.schema);
+  }
+  return [...byOwner.entries()]
+    .map(([owner, schemas]) => ({ owner, schemas: [...schemas].sort() }))
+    .sort((a, b) => a.owner.localeCompare(b.owner));
+}
+
+/**
+ * ONE catalog read answering every question the preflight has, for every declared owner at once
+ * — so the refusal can name the COMPLETE list. A first-failure refusal makes the operator
+ * provision one role, re-run, and discover the next; the whole point is that they see the work.
+ *
+ * `has_schema_privilege` throws on a schema that does not exist, so the schema is LEFT JOINed
+ * and the privilege only evaluated when it is really there.
+ */
+export function ownerPreflightSql(requirements: OwnerRequirement[]): string {
+  const pairs = requirements.flatMap((r) => r.schemas.map((s) => `(${escapeLiteral(r.owner)}, ${escapeLiteral(s)})`));
+  return `
+WITH declared(owner_name, schema_name) AS (VALUES ${pairs.join(', ')})
+SELECT
+  CURRENT_USER AS builder,
+  -- Which mechanism the applier may use. A SUPERUSER (RDS: an rds_superuser member) can hand an
+  -- object to a role it is not a member of, so it creates as itself and ALTERs the owner —
+  -- demanding SET ROLE of it would force CREATE-on-schema onto the very role that is supposed to
+  -- hold none. Everyone else creates AS the owner. Same shape as security-catalog's rule.
+  (
+    SELECT b.rolsuper OR EXISTS (
+      SELECT 1 FROM pg_auth_members m JOIN pg_roles g ON g.oid = m.roleid
+      WHERE m.member = b.oid AND g.rolname = 'rds_superuser'
+    )
+    FROM pg_roles b WHERE b.rolname = CURRENT_USER
+  ) AS builder_is_superuser,
+  d.owner_name,
+  d.schema_name,
+  (r.oid IS NOT NULL) AS role_exists,
+  (n.oid IS NOT NULL) AS schema_exists,
+  r.rolsuper AS owner_is_superuser,
+  CASE WHEN r.oid IS NULL THEN NULL ELSE pg_has_role(CURRENT_USER, r.oid, 'SET') END AS can_set_role,
+  CASE WHEN r.oid IS NULL OR n.oid IS NULL THEN NULL
+       ELSE has_schema_privilege(r.oid, n.oid, 'CREATE') END AS owner_can_create
+FROM declared d
+LEFT JOIN pg_roles r ON r.rolname = d.owner_name
+LEFT JOIN pg_namespace n ON n.nspname = d.schema_name
+ORDER BY d.owner_name, d.schema_name
+`.trim();
+}
+
+export interface OwnerPreflightRow {
+  builder?: unknown;
+  builder_is_superuser?: unknown;
+  owner_name: string;
+  schema_name: string;
+  role_exists?: unknown;
+  schema_exists?: unknown;
+  owner_is_superuser?: unknown;
+  can_set_role?: unknown;
+  owner_can_create?: unknown;
+}
+
+const truthy = (v: unknown): boolean => v === true || v === 't' || v === 'true';
+
+/**
+ * The mechanism this builder may use, read off the same preflight rows.
+ *
+ * Defaults to `set-role` when the column is absent — an older caller or a fixture — because that
+ * is the mechanism that works for everyone. Guessing `alter-owner` for an unknown builder would
+ * emit an ALTER a non-superuser cannot run, and fail mid-batch.
+ */
+export function builderOwnerMode(rows: OwnerPreflightRow[]): OwnerApplyMode {
+  return rows.some((r) => truthy(r.builder_is_superuser)) ? 'alter-owner' : 'set-role';
+}
+
+/**
+ * The refusal text, or null when every declared owner is usable.
+ *
+ * Three ways a declared owner fails, all named at once with the exact statement that fixes each:
+ *
+ *   1. THE ROLE DOES NOT EXIST. The build refuses and does NOT create it. A role is
+ *      cluster-scoped and a security principal, and a principal invented by a tool cannot know
+ *      the design it stands in for — it would arrive with no memberships, no grants and no
+ *      review, wearing the name of something that was supposed to be deliberate.
+ *   2. THE BUILDER CANNOT ASSUME IT. The CREATE runs under `SET ROLE <owner>`, so membership
+ *      WITH SET TRUE is required. `WITH INHERIT FALSE` is part of the fix on purpose: it lets
+ *      the builder become the owner without silently inheriting the owner's privileges.
+ *   3. THE OWNER CANNOT CREATE IN THE SCHEMA. Same mechanism — the CREATE happens AS the owner,
+ *      so the owner needs CREATE on the schema the object lives in. A schema that does not exist
+ *      yet counts: this build creates it as the BUILDER, and the owner will not hold CREATE on it.
+ */
+export function ownerPreflightRefusal(rows: OwnerPreflightRow[]): string | null {
+  const builder = rows.find((r) => r.builder != null)?.builder;
+  const builderName = builder == null ? 'the connecting role' : String(builder);
+  const missing = new Set<string>();
+  const unassumable = new Set<string>();
+  const noCreate: Array<{ owner: string; schema: string; exists: boolean }> = [];
+
+  // A superuser builder creates as itself and ALTERs the owner, so it needs neither membership in
+  // the owner nor CREATE on the owner's behalf. Refusing on either would be a false refusal that
+  // demands a privilege expansion onto a role designed to hold none. Only "the role must exist"
+  // survives, because no mechanism can hand an object to a principal that is not there.
+  const alterOwner = builderOwnerMode(rows) === 'alter-owner';
+
+  for (const row of rows) {
+    const owner = String(row.owner_name);
+    if (!truthy(row.role_exists)) { missing.add(owner); continue; }
+    if (alterOwner) continue;
+    if (!truthy(row.can_set_role)) unassumable.add(owner);
+    // A superuser owner holds CREATE everywhere, including in a schema this build is about to
+    // make — there is nothing to refuse.
+    if (truthy(row.owner_is_superuser)) continue;
+    if (!truthy(row.schema_exists)) noCreate.push({ owner, schema: String(row.schema_name), exists: false });
+    else if (!truthy(row.owner_can_create)) noCreate.push({ owner, schema: String(row.schema_name), exists: true });
+  }
+
+  if (!missing.size && !unassumable.size && !noCreate.length) return null;
+
+  const lines: string[] = [
+    `declared function owner(s) cannot be enacted by '${builderName}' — refused before any DDL, so nothing is half-applied:`,
+  ];
+  for (const owner of [...missing].sort()) {
+    lines.push(
+      `  NO SUCH ROLE  '${owner}' does not exist in this cluster. The build will not create it —`,
+      `      a role is a security principal, and one invented by a tool arrives with no memberships,`,
+      `      no grants and no review. Provision it, then re-run:  CREATE ROLE ${owner} NOLOGIN;`,
+    );
+  }
+  for (const owner of [...unassumable].sort()) {
+    lines.push(
+      `  CANNOT SET ROLE  '${builderName}' cannot assume '${owner}'. The CREATE runs as the owner:`,
+      `      GRANT ${owner} TO ${builderName} WITH INHERIT FALSE, SET TRUE;`,
+    );
+  }
+  for (const { owner, schema, exists } of noCreate) {
+    lines.push(
+      `  NO CREATE ON SCHEMA  '${owner}' cannot create in schema "${schema}"${exists ? '' : ' (which this build creates as the builder)'}:`,
+      `      GRANT CREATE ON SCHEMA ${schema} TO ${owner};`,
+    );
+  }
+  return lines.join('\n');
+}
+
+export function renderReconcileSql(plan: ReconcilePlan, source: SourceObject[], ownerMode: OwnerApplyMode = 'set-role'): RenderedReconcile {
   const srcById = new Map(source.map((o) => [o.identity, o]));
   const statements: string[] = [];
   const record: string[] = [];
@@ -214,14 +445,14 @@ export function renderReconcileSql(plan: ReconcilePlan, source: SourceObject[]):
       case 'replace': {
         const obj = srcById.get(action.identity);
         if (!obj) throw new Error(`replace action for ${action.identity} has no source object`);
-        statements.push(...objectSql(obj).map(ensureOrReplace));
+        statements.push(...objectSql(obj, ownerMode).map(ensureOrReplace));
         record.push(action.identity);
         break;
       }
       case 'create': {
         const obj = srcById.get(action.identity);
         if (!obj) throw new Error(`create action for ${action.identity} has no source object`);
-        statements.push(...objectSql(obj));
+        statements.push(...objectSql(obj, ownerMode));
         record.push(action.identity);
         break;
       }

package/src/cli/derived-compile.ts

@@ -194,9 +194,20 @@ function renderFunction(fn: FunctionDescriptor): { sql: string; attachments: Att
     .join(', ');
   const returns = typeof fn.returns === 'string' ? fn.returns : `SETOF ${refName(fn.returns.setof)}`;
   const volatility = fn.volatility === 'volatile' ? '' : ` ${fn.volatility.toUpperCase()}`;
-  const security = fn.security === 'definer'
-    ? ` SECURITY DEFINER SET search_path = ${(fn.searchPath ?? []).join(', ')}`
+  const definer = fn.security === 'definer' ? ' SECURITY DEFINER' : '';
+  // The pin is INDEPENDENT of the security mode, in both directions.
+  //
+  // `'unpinned'` emits no `SET search_path` at all — that is the whole point of the sentinel:
+  // a brownfield definer function that genuinely has none is now declarable, instead of the
+  // pull inventing `pg_catalog` and the build applying the invention for real.
+  //
+  // And a pin on an INVOKER function is emitted too. It used to be silently dropped, so a model
+  // could declare one, the build would not apply it, and the differ (which never read proconfig)
+  // would not notice — a declared property with no effect and no complaint.
+  const pin = Array.isArray(fn.searchPath) && fn.searchPath.length > 0
+    ? ` SET search_path = ${fn.searchPath.join(', ')}`
     : '';
+  const security = `${definer}${pin}`;
   const tag = dollarTag(fn.body);
   const signature = functionSignature(target, fn);
   return {
@@ -321,10 +332,12 @@ function make(kind: SourceObject['kind'], rawName: string, sql: string, attachme
     kind, schema, name,
     identity: extra.identity ?? `${schema}.${name}`,
     sql, attachments,
-    hash: hashSourceContent(sql, attachments),
+    hash: hashSourceContent(sql, attachments, extra.owner),
     // bodyHash excludes PLAIN grants (column-scoped grants stay in — attacl isn't drift-checked, so
     // a column-grant change must still rebuild). Equal across an authz-only plain-grant change.
-    bodyHash: hashSourceContent(sql, attachments.filter((a) => !isPlainGrantAttachment(a))),
+    // The OWNER stays in: changing who a SECURITY DEFINER function (or a non-invoker view)
+    // executes as is a rebuild, not an authz delta, so it must not be routed to a bare GRANT diff.
+    bodyHash: hashSourceContent(sql, attachments.filter((a) => !isPlainGrantAttachment(a)), extra.owner),
     file: DECLARED, seq,
     ...extra,
   });
@@ -369,18 +382,23 @@ export function compileDerived(models: readonly ModelDescriptor[], derived: read
     switch (d.kind) {
       case 'view': {
         const { sql, attachments } = renderView(d);
-        nodes.push({ identity, deps: depIdentities(d.dependsOn), build: make('view', d.name, sql, attachments, { declaredDeps: declaredIdentities(d.dependsOn) }) });
+        // A15: the owner rides on the object, so it enters the content hash (a view that
+        // changes owner IS a different object) and the applier can create it under SET ROLE.
+        nodes.push({ identity, deps: depIdentities(d.dependsOn), build: make('view', d.name, sql, attachments, { declaredDeps: declaredIdentities(d.dependsOn), ...(d.owner ? { owner: d.owner } : {}) }) });
         break;
       }
       case 'materialized view': {
         const { sql, attachments } = renderMaterializedView(d);
-        nodes.push({ identity, deps: depIdentities(d.dependsOn), build: make('materialized view', d.name, sql, attachments, { declaredDeps: declaredIdentities(d.dependsOn) }) });
+        nodes.push({ identity, deps: depIdentities(d.dependsOn), build: make('materialized view', d.name, sql, attachments, { declaredDeps: declaredIdentities(d.dependsOn), ...(d.owner ? { owner: d.owner } : {}) }) });
         break;
       }
       case 'function': {
         const { sql, attachments } = renderFunction(d);
         const setofDep = typeof d.returns === 'string' ? [] : depIdentities([d.returns.setof]);
-        nodes.push({ identity, deps: [...depIdentities(d.dependsOn), ...setofDep], build: make('function', d.name, sql, attachments, { identity }) });
+        // The pin rides STRUCTURALLY as well as inside `sql`, so the differ can compare it
+        // against the live catalog directly instead of only against a recorded hash. It is not
+        // in the hash (it is already inside `sql`), so carrying it moves nobody's fingerprint.
+        nodes.push({ identity, deps: [...depIdentities(d.dependsOn), ...setofDep], build: make('function', d.name, sql, attachments, { identity, ...(d.owner ? { owner: d.owner } : {}), ...(d.searchPath !== undefined ? { searchPath: d.searchPath } : {}) }) });
         break;
       }
       case 'sql': {

package/src/cli/derived-grants.ts

@@ -99,20 +99,113 @@ export function parseGrantAttachments(attachments: readonly Attachment[]): Parse
  * The idempotent REVOKE/GRANT delta between the declared contract and the live ACLs —
  * the table path's reconcileGrants, per derived object. Empty when they match.
  */
+export interface ObjectGrantDiff {
+  statements: string[];
+  /** REVOKEs withheld because ownership made the two sides incomparable, with the reason. */
+  suppressed: string[];
+}
+
+/**
+ * Ownership context for a FUNCTION's grant diff. Absent for relations.
+ *
+ * Owner-implicit EXECUTE is excluded from both grant reads (`grantee <> proowner`), which is
+ * correct in isolation — an owner's privileges are not grants. But it means the SET of
+ * non-owner grants is computed RELATIVE TO THE OWNER, so two sides with different owners
+ * produce two different sets for the same function, and the differ reconciles a difference
+ * that is purely ownership.
+ *
+ * Measured by a consumer, 2026-08-10: their local `resolve_user_slug` is owned by
+ * `outbound_migrator` (owner-implicit, so the pull rendered NO privilege), while on stage the
+ * same function is owned by `slug_resolver` and `outbound_migrator` holds an EXPLICIT grant.
+ * The differ planned `REVOKE EXECUTE ON api.resolve_user_slug FROM outbound_migrator` — a real
+ * access removal minted from an ownership difference. They did not apply it.
+ */
+export interface GrantOwnerContext {
+  /** The owner the DECLARED grant set was computed against, when the models declare one. */
+  declared?: string;
+  /** The owner the LIVE grant set was computed against (`pg_get_userbyid(proowner)`). */
+  live?: string;
+}
+
+/**
+ * The idempotent REVOKE/GRANT delta between the declared contract and the live ACLs —
+ * the table path's reconcileGrants, per derived object. Empty when they match.
+ *
+ * When `owners` is supplied (functions) and the two sides cannot be shown to have been
+ * computed against the SAME owner, REVOKEs are WITHHELD and reported. GRANTs still flow: a
+ * redundant GRANT is noise, a wrong REVOKE removes access that was really there. Failing to
+ * revoke is the recoverable error and it is never silent.
+ *
+ * This withholds some legitimate revokes on a project that has not declared `owner` yet —
+ * deliberately. Declaring the owner restores full capability, and until then the tooling says
+ * plainly what it is not doing rather than guessing.
+ */
 export function diffObjectGrants(
   target: string,
   declared: Record<string, string[]>,
   live: Record<string, string[]>,
-): string[] {
+  owners?: GrantOwnerContext,
+): ObjectGrantDiff {
   const out: string[] = [];
+  const suppressed: string[] = [];
+  // WHICH GRANTEE, not which object. An owner-implicit privilege can only make a grantee
+  // appear or disappear if THAT GRANTEE is an owner on one of the two sides — the owner's own
+  // rows are what each read excludes. So suppression is per-grantee, and every other revoke
+  // still flows.
+  //
+  // This matters concretely: PUBLIC is a pseudo-role that can never own an object, so a
+  // `REVOKE ... FROM PUBLIC` is NEVER explained by ownership. An earlier, object-scoped
+  // version of this guard swallowed exactly that revoke — a hand-run `GRANT EXECUTE TO PUBLIC`
+  // on a managed function stopped being cleaned up, turning a privilege-escalation cleanup
+  // into a silent no-op. Caught by __tests__/integration/derived-drift.test.ts against a real
+  // database.
+  //
+  // The declared owner is only known once the models declare one (`defineFunction owner`).
+  // Until then the pull-time owner is unrecorded, so a grantee that WAS the pull-time owner
+  // cannot be identified — that case is closed by db:pull emitting `owner`, not here. What we
+  // can always identify is the LIVE owner, and that is the half that produces the asymmetry
+  // in the direction that removes access.
+  const ownerish = new Set([owners?.declared, owners?.live].filter((o): o is string => !!o));
+  const suppressibleGrantee = (grantee: string): boolean =>
+    owners?.live !== undefined && grantee !== 'PUBLIC' && ownerish.has(grantee);
+  // NORMALIZATION, and it is a different move from the suppression above.
+  //
+  // The LIVE owner holds every privilege implicitly, and the live read excludes exactly those
+  // rows. So when the two sides share a basis — the models declare the live owner, or declare no
+  // owner at all — a declared grant TO that owner is already true and unreadable. Minting it
+  // produces a GRANT the next read still cannot see: a statement that runs on every reconcile,
+  // forever, and never converges. Measured as 31 of them on one consumer's function set.
+  //
+  // Both directions drop, because both are vacuous: an owner's implicit privileges cannot be
+  // granted (they are already held) and cannot be revoked (they follow ownership, not the ACL).
+  // This is not a withheld statement, so it is not reported as one.
+  //
+  // It applies ONLY when the bases agree. A declared owner that differs from the live one means
+  // ownership itself is converging, the two grant sets were computed against different owners,
+  // and that case stays with the suppression rule above.
+  const sameBasis = owners?.declared === undefined || owners.declared === owners.live;
+  const ownerImplicit = (grantee: string): boolean =>
+    owners?.live !== undefined && grantee !== 'PUBLIC' && grantee === owners.live && sameBasis;
   const grantees = new Set([...Object.keys(declared), ...Object.keys(live)]);
   for (const grantee of [...grantees].sort()) {
+    if (ownerImplicit(grantee)) continue;
     const want = new Set(declared[grantee] ?? []);
     const have = new Set(live[grantee] ?? []);
     const toRevoke = [...have].filter((p) => !want.has(p)).sort();
     const toGrant = [...want].filter((p) => !have.has(p)).sort();
-    if (toRevoke.length) out.push(`REVOKE ${toRevoke.join(', ')} ON ${target} FROM ${grantee}`);
+    if (toRevoke.length) {
+      if (!suppressibleGrantee(grantee)) {
+        out.push(`REVOKE ${toRevoke.join(', ')} ON ${target} FROM ${grantee}`);
+      } else {
+        const why = grantee === owners!.live
+          ? `'${grantee}' is the function's live OWNER, whose implicit privileges are excluded from both grant reads — so this difference is ownership, not a grant`
+          : `'${grantee}' is the function's declared owner (live owner: ${owners!.live}), and an owner's implicit privileges are excluded from both grant reads`;
+        suppressed.push(
+          `${target}: withheld REVOKE ${toRevoke.join(', ')} FROM ${grantee} — ${why}. An owner's implicit privileges are excluded from both reads, so the two grant sets are not comparable and this revoke may remove access that is really there. Declare the function's owner to restore revokes.`,
+        );
+      }
+    }
     if (toGrant.length) out.push(`GRANT ${toGrant.join(', ')} ON ${target} TO ${grantee}`);
   }
-  return out;
+  return { statements: out, suppressed };
 }