ALTER DEFAULT PRIVILEGES je per-databáze — nové objekty mají v každé DB jiné ACL

import { Aside } from ‘@astrojs/starlight/components’;

Migrace nesmí spoléhat na default privileges — každému vytvořenému objektu nastav ACL explicitně (REVOKE ALL vč. vlastníkovské role, pak cílené GRANTy).

Symptom

Migrace validovaná na hlavní scratch databázi (inicializovaný image s default privileges) dávala jiný ACL otisk než tatáž migrace na čerstvě vytvořené databázi (CREATE DATABASE klonuje template1 bez defaultů). Auditní tabulka navíc na „bohatší” DB tiše dostala plná práva pro aplikační role — na append-only auditu nepřijatelné.

Root cause

ALTER DEFAULT PRIVILEGES se ukládá do pg_default_acl konkrétní databáze. Platformy jako Supabase je nastavují v hlavní DB (GRANT ALL novým tabulkám/funkcím pro aplikační role); template1 je nemá. Bonus: při ALTER TABLE ... OWNER TO nova_role PostgreSQL přepíše grantora existujících grantů na nového vlastníka — vznikají ACL řádky, které v „chudé” DB vůbec neexistují.

Fix

-- po CREATE TABLE/FUNCTION v migraci VŽDY:
REVOKE ALL ON public.audit_tab FROM PUBLIC, app_anon, app_auth, app_service, superrole;
GRANT SELECT ON public.audit_tab TO app_service;   -- jen explicitní, cílené granty

Jak se tomu vyvarovat v jiných systémech

• Detection: spustit migraci na DB s defaulty i na čisté DB a diffnout aclexplode výstup.
• Anti-pattern: „granty doplní defaulty”; validace jen na jednom typu prostředí.
• Lepší přístup: explicitní ACL v migraci + ACL složka v pre/post manifestu migrace.