Default Privileges

Das Problem in einem Beispiel

SET ROLE app_owner;
CREATE TABLE orders (id serial primary key);
GRANT SELECT ON ALL TABLES IN SCHEMA app TO reader;

-- Spaeter, in einer neuen Migration:
CREATE TABLE customers (id serial primary key);

SET ROLE reader;
SELECT * FROM customers;
-- ERROR: permission denied for table customers

reader hatte SELECT auf alle Tabellen, die zum Zeitpunkt des GRANT existierten — orders. Die später angelegte customers ist davon nicht betroffen.

Die Lösung: ALTER DEFAULT PRIVILEGES

ALTER DEFAULT PRIVILEGES IN SCHEMA app
    GRANT SELECT ON TABLES TO reader;

Übersetzt: „Ab jetzt — sobald jemand in Schema app eine neue Tabelle anlegt, soll reader automatisch SELECT bekommen.”

Damit greift die Regel auf alle zukünftig erzeugten Tabellen. Die existierenden bleiben unverändert; für die brauchst du weiterhin den klassischen GRANT SELECT ON ALL TABLES ….

Faustregel: bei einem neuen Read-Only-User immer beides ausführen:

-- 1. Bestehendes:
GRANT USAGE ON SCHEMA app TO reader;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO reader;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA app TO reader;

-- 2. Zukuenftiges:
ALTER DEFAULT PRIVILEGES IN SCHEMA app
    GRANT SELECT ON TABLES TO reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA app
    GRANT SELECT ON SEQUENCES TO reader;

Worauf wirken Default Privileges?

Du kannst Defaults für die folgenden Objekttypen setzen:

Der wichtigste Stolperstein: GRANTOR

Defaults sind immer an eine bestimmte erzeugende Rolle gebunden — den GRANTOR. In Klartext: die Regel greift nur, wenn die neue Tabelle von derselben Rolle erstellt wird, die das ALTER DEFAULT PRIVILEGES ausgeführt hat.

-- Als app_owner:
ALTER DEFAULT PRIVILEGES IN SCHEMA app
    GRANT SELECT ON TABLES TO reader;

-- Sind app_owner Migrationen, greift die Regel.

-- Wenn aber eine andere Rolle (z. B. ein Migrations-User
-- "migrator") die Tabellen erstellt:
SET ROLE migrator;
CREATE TABLE app.invoices (...);
-- reader bekommt KEIN SELECT auf invoices.

Lösung: explizit für die richtige Rolle setzen.

ALTER DEFAULT PRIVILEGES FOR ROLE migrator IN SCHEMA app
    GRANT SELECT ON TABLES TO reader;

Wer mehrere Rollen Tabellen erzeugen lässt, braucht das ALTER DEFAULT PRIVILEGES FOR ROLE … für jede dieser Rollen. Praktischer ist, das im Migrations-Setup zu vereinheitlichen: eine Owner-Rolle für alle Migrationen, einmal Defaults setzen, fertig.

Pro Schema vs. global

Ohne IN SCHEMA gilt die Regel datenbankweit — für jede zukünftige Tabelle in jedem Schema:

ALTER DEFAULT PRIVILEGES
    GRANT SELECT ON TABLES TO reader;

Das ist häufig zu großzügig. In den meisten Setups gibt es ein App-Schema, ein paar Werkzeug-Schemas (migrations, tmp) und das public-Schema. Pro-Schema-Defaults sind expliziter und sicherer.

Defaults inspizieren

Im psql:

myapp=# \ddp
                          Default access privileges
   Owner    | Schema | Type  |     Access privileges
------------+--------+-------+---------------------------
 app_owner  | app    | table | reader=r/app_owner
 app_owner  | app    | seq   | reader=r/app_owner

Oder direkt im Katalog:

SELECT pg_get_userbyid(defaclrole)   AS grantor,
       nspname                       AS schema,
       defaclobjtype                 AS object_type,
       defaclacl                     AS privileges
FROM pg_default_acl
LEFT JOIN pg_namespace ON pg_namespace.oid = defaclnamespace;

defaclobjtype-Werte: r = relation (Tabelle), S = sequence, f = function, T = type, n = schema.

Zurücknehmen

Symmetrisch:

ALTER DEFAULT PRIVILEGES IN SCHEMA app
    REVOKE SELECT ON TABLES FROM reader;

Wichtig: das wirkt nur auf die Defaults selbst (für künftige Objekte). Schon vergebene Privilegien auf existierende Tabellen bleiben — die musst du separat mit klassischem REVOKE zurückziehen.

Weiterführende Ressourcen

Externe Quellen

• ALTER DEFAULT PRIVILEGES – PostgreSQL Documentation
• pg_default_acl – PostgreSQL Documentation
• psql \ddp – Default access privileges output
• Release Notes 15: ALTER DEFAULT PRIVILEGES on schemas

Verwandte Artikel

• GRANT/REVOKE — Grundlagen
• Read-Only-Benutzer anlegen
• Webapp-Benutzer mit Least-Privilege
• Alle Rechte auf bestehende Objekte vergeben