GRANT und REVOKE

Privilegien-Katalog

Welche Privilegien Postgres kennt, hängt vom Objekttyp ab:

ALL PRIVILEGES (oder kurz ALL) ist eine bequeme Abkürzung für den kompletten Satz des jeweiligen Objekttyps.

Grundsyntax

GRANT SELECT, INSERT ON orders TO app_user;
GRANT USAGE ON SCHEMA app TO app_user;
GRANT EXECUTE ON FUNCTION calc_tax(numeric) TO app_user;
GRANT CONNECT ON DATABASE myapp TO app_user;

REVOKE INSERT ON orders FROM app_user;
REVOKE ALL ON SCHEMA app FROM app_user;

Die Syntax ist konsistent: GRANT <privs> ON <objtype> <objname> TO <role>. <objtype> ist optional, wenn es sich aus dem Kontext ergibt (Standard ist TABLE).

Mehrere Objekte gleichzeitig

Postgres kennt drei nützliche Bulk-Varianten:

-- Alle existierenden Tabellen in einem Schema:
GRANT SELECT ON ALL TABLES IN SCHEMA app TO reader;

-- Alle Sequenzen (haeufig zusammen mit INSERT-Rechten gebraucht):
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA app TO app_user;

-- Alle Funktionen:
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA app TO app_user;

Wichtig: das wirkt nur auf existierende Objekte. Tabellen, die nach diesem GRANT neu erstellt werden, sind nicht automatisch eingeschlossen. Wer das will, braucht zusätzlich ALTER DEFAULT PRIVILEGES (eigener Artikel: Default Privileges).

Spalten-Level-Privilegien

Postgres erlaubt Privilegien auch auf einzelne Spalten statt der ganzen Tabelle:

-- Reader darf nur die nicht-sensitiven Spalten lesen:
GRANT SELECT (id, name, created_at) ON users TO reader;

-- Tabellen-weiter SELECT NICHT vergeben.

In der Praxis selten genutzt — meist setzt man stattdessen Views oder Row-Level Security ein, weil Spalten-Privilegien nicht alle Tools sauber unterstützen. Aber gut zu wissen, dass es geht.

PUBLIC — die Pseudo-Rolle „alle”

PUBLIC ist eine eingebaute „Rolle”, die jeden Datenbank-User repräsentiert. Privilegien, die an PUBLIC gehen, gelten für jeden:

GRANT SELECT ON pg_stat_activity TO PUBLIC;

Postgres vergibt selbst eine handvoll Default-Privilegien an PUBLIC — z. B. EXECUTE auf alle Funktionen, USAGE auf alle Languages und (bis PG 14) CREATE auf das public-Schema. Letzteres ist ein häufiger Sicherheits-Talkingpoint.

Seit PG 15 sind die Defaults restriktiver:

Wer eine Datenbank von einer alten auf eine neue Version migriert, sollte das prüfen — Anwendungen, die sich auf das alte Verhalten verließen, können brechen.

WITH GRANT OPTION

GRANT … WITH GRANT OPTION macht den Empfänger zu einem Privileg-Vermittler. Er darf das Privileg seinerseits weitergeben:

GRANT SELECT ON orders TO team_lead WITH GRANT OPTION;

-- team_lead darf nun selbst:
GRANT SELECT ON orders TO new_intern;

Wer ein mit GRANT OPTION vergebenes Privileg zurückzieht, muss CASCADE angeben, falls dadurch wiederum bei Dritten Privilegien wegfallen:

REVOKE SELECT ON orders FROM team_lead;
-- ERROR: dependent privileges exist
REVOKE SELECT ON orders FROM team_lead CASCADE;
-- OK: alle daraus abgeleiteten GRANTs werden mit entfernt

Privilegien anzeigen

In psql:

myapp=# \dp orders
                                 Access privileges
 Schema |  Name  | Type  |     Access privileges     | Column privileges | Policies
--------+--------+-------+---------------------------+-------------------+----------
 public | orders | table | app_owner=arwdDxt/app_owner+|                   |
        |        |       | app_user=arwd/app_owner   |                   |

Der kryptische Code übersetzt sich:

app_user=arwd/app_owner heißt also: User app_user darf SELECT/INSERT/UPDATE/DELETE; das Privileg wurde von app_owner vergeben.

Weiterführende Ressourcen

Externe Quellen

• Privileges – PostgreSQL Documentation
• GRANT – PostgreSQL Documentation
• REVOKE – PostgreSQL Documentation
• Release Notes 15: PUBLIC schema permissions
• psql \dp – Access privileges output format

Verwandte Artikel

• Rollen und Privilegien — Übersicht
• Default Privileges
• Predefined Roles
• Schemas und search_path
• Alle Rechte auf bestehende Objekte vergeben