pg_permission_audit — Wer hat Zugriff auf was in PostgreSQL? — Blog

Was macht dieses Tool?

pg_permission_audit erstellt eine vollständige Karte aller Rollen, Grants und Zugriffsrechte in der Datenbank. Es zeigt nicht nur, welche Rechte direkt vergeben wurden, sondern verfolgt auch die Vererbungskette über Rollenmitgliedschaften. Das Ergebnis ist ein klares Bild: Wer kann auf welche Tabellen mit welchen Operationen zugreifen — und warum.

Wie wird es aufgerufen?

Claude CLI (natürliche Sprache)

● ● ● Claude CLI — Berechtigungs-Audit

claude> Wer hat Zugriff auf welche Tabellen?

▶ Calling tools...
→ pg_connect { "profile": "production-db" }
✓ Verbunden mit production-db (PostgreSQL 16.x)

→ pg_permission_audit {}

Berechtigungs-Audit: 2 Rollen, 1 Schema analysiert

👤 PUBLIC
public.pg_stat_statements — SELECT (is_grantable: NO)

👤 mcp_test
public.partitioned_events — SELECT, INSERT, UPDATE, DELETE (is_grantable: YES)

MCP Protocol (programmatisch)

● ● ● MCP Protocol — Verbindung

// Programmatic invocation via MCP SDK
const result = await client.callTool("pg_connect", { "profile": "production-db" });

// Response:
{ "status": "connected", "version": "PostgreSQL 16.x" }

● ● ● MCP Protocol — Berechtigungs-Audit

// Programmatic invocation via MCP SDK
const result = await client.callTool("pg_permission_audit", {});

// Response:
[
{
    "grantee": "PUBLIC",
    "table_schema": "public",
    "table_name": "pg_stat_statements",
    "privilege_type": "SELECT",
    "is_grantable": "NO"
},
{
    "grantee": "mcp_test",
    "table_schema": "public",
    "table_name": "partitioned_events",
    "privilege_type": "DELETE",
    "is_grantable": "YES"
},
{
    "grantee": "mcp_test",
    "table_schema": "public",
    "table_name": "partitioned_events",
    "privilege_type": "INSERT",
    "is_grantable": "YES"
},
{
    "grantee": "mcp_test",
    "table_schema": "public",
    "table_name": "partitioned_events",
    "privilege_type": "SELECT",
    "is_grantable": "YES"
},
{
    "grantee": "mcp_test",
    "table_schema": "public",
    "table_name": "partitioned_events",
    "privilege_type": "UPDATE",
    "is_grantable": "YES"
}
]

Was passiert unter der Haube?

Das Tool führt mehrere Queries gegen den PostgreSQL-Systemkatalog aus:

Rollen und Attribute

-- Alle benutzerdefinierten Rollen mit ihren Attributen
SELECT rolname, rolsuper, rolcanlogin, rolcreatedb, rolcreaterole, rolconnlimit, rolvaliduntil FROM pg_roles WHERE rolname NOT LIKE 'pg_%' ORDER BY rolname;

Rollenmitgliedschaften

-- Vererbungskette: Welche Rolle erbt von welcher?
SELECT r.rolname AS role, m.rolname AS member_of FROM pg_auth_members am JOIN pg_roles r ON am.member = r.oid JOIN pg_roles m ON am.roleid = m.oid ORDER BY r.rolname;

Tabellen-Privilegien

-- Tabellenbasierte Grants aus information_schema
SELECT grantee, table_schema, table_name, privilege_type FROM information_schema.role_table_grants WHERE table_schema NOT IN ('pg_catalog', 'information_schema') ORDER BY grantee, table_schema, table_name;

Ausgabe im Detail

grantee — Name der Rolle oder PUBLIC
table_schema — Schema der Tabelle
table_name — Name der Tabelle
privilege_type — Typ des Rechts: SELECT, INSERT, UPDATE, DELETE
is_grantable — Ob die Rolle das Recht weitergeben kann (YES/NO)

Praxis-Tipp: Jeder Superuser hat implizit Zugriff auf alles — deshalb zeigt das Tool für Superuser-Rollen keine expliziten Privileges an. Die superuser_count-Metrik hilft, übermäßige Superuser-Nutzung zu erkennen.

Was testet die Testsuite?

Die Testsuite validiert pg_permission_audit gegen eine PostgreSQL-Instanz mit 3 Testrollen (mcp_test_readonly, mcp_test_readwrite, mcp_test_admin) mit unterschiedlichen Grant-Stufen:

● ● ● vitest run — Testsuite

✓ pg_permission_audit > lists all roles with attributes
✓ pg_permission_audit > includes privilege details per role
✓ pg_permission_audit > detects superuser status correctly

Test Files 1 passed (1)
Tests 3 passed (3)
Duration 215ms

Testdaten-Szenario

Die Seed-Datenbank enthält:

mcp_test_readonly — SELECT auf alle Tabellen in app und perf
mcp_test_readwrite — SELECT, INSERT, UPDATE, DELETE auf app; SELECT, INSERT auf perf
mcp_test_admin — SUPERUSER mit vollem Zugriff

Die Tests validieren, dass:

Alle Rollen mit ihren Attributen (superuser, canlogin) aufgelistet werden
Die Privilege-Details pro Rolle korrekt zurückgegeben werden
Der Superuser-Status korrekt erkannt wird

Zusammenfassung

pg_roles + pg_auth_members

Datenquellen

Ausgabefelder

Tests

read-only

Typ

pg_permission_audit beantwortet die wichtigste Sicherheitsfrage jeder Datenbank: Wer hat Zugriff auf was — und warum? Es ersetzt das manuelle Abfragen von pg_roles, pg_auth_members und information_schema.role_table_grants durch einen einzigen, strukturierten Audit-Bericht.

In Kombination mit pg_gdpr_audit (→ Wo liegt PII?) bildet es den Kern des /pg-comply Workflow-Skills.

pg_permission_audit — Wer hat Zugriff auf was in PostgreSQL?