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