Ownership und Besitz

Was Owner können dürfen

Der Owner eines Objekts darf:

• das Objekt droppen (DROP TABLE, DROP FUNCTION, …)
• es umbenennen (ALTER … RENAME TO)
• es ändern (Spalten hinzufügen, Constraints, …)
• den Owner wechseln an eine andere Rolle, in der er Mitglied ist
• seinerseits Privilegien an andere vergeben (GRANT)

Diese Rechte bekommt niemand sonst — auch ein User mit ALL PRIVILEGES darf eine Tabelle nicht droppen, wenn er nicht Owner ist. Es gibt nur zwei Ausnahmen: Superuser (dürfen alles) und Mitglieder der Owner-Rolle (über Inheritance).

CREATE ROLE app_owner;
CREATE ROLE app_user LOGIN PASSWORD 'changeme';

SET ROLE app_owner;
CREATE TABLE orders (id serial primary key, total numeric);
-- orders gehoert jetzt app_owner

GRANT SELECT, INSERT, UPDATE, DELETE ON orders TO app_user;

SET ROLE app_user;
DELETE FROM orders;     -- OK (DELETE-Privileg)
DROP TABLE orders;      -- ERROR: must be owner of table orders

Default-Owner

Wenn du CREATE TABLE foo (...) ohne weiteres ausführst, wird der aktuelle Effektiv-User (current_user) zum Owner. Bei einem SET ROLE app_owner; CREATE TABLE …;-Pattern landet das Eigentum entsprechend bei app_owner.

Das ist wichtig für saubere Setups: Migrations-Tools sollten unter dem Schema-Owner laufen, damit alle erzeugten Objekte zentral diesem User gehören. Sonst hast du nach drei Migrationen eine Mischung von Tabellen-Ownern, die zu späteren Problemen führt.

Owner ändern

ALTER TABLE orders OWNER TO app_owner;
ALTER FUNCTION calculate_tax(numeric) OWNER TO app_owner;
ALTER SCHEMA app OWNER TO app_owner;
ALTER DATABASE myapp OWNER TO app_owner;

Voraussetzungen, um den Owner zu wechseln:

1. Du musst aktueller Owner sein (oder Superuser).
2. Du musst Mitglied der Ziel-Rolle sein.
3. Bei ALTER DATABASE … OWNER TO brauchst du zusätzlich CREATEDB-Recht oder Superuser-Status.

Was passiert beim DROP des Owners?

Hier liegt der häufigste Stolperstein. Wenn du eine Rolle droppen willst, die noch Objekte besitzt, lehnt Postgres ab:

myapp=# DROP ROLE app_owner;
ERROR:  role "app_owner" cannot be dropped because some objects depend on it
DETAIL:  owner of table orders, owner of schema app, ...

Postgres weigert sich aus gutem Grund: würden die Objekte einfach „herrenlos” sein, könnte niemand mehr sicher mit ihnen arbeiten. Du musst also vorher den Besitz übertragen oder die Objekte droppen.

REASSIGN OWNED + DROP OWNED — das Aufräum-Pattern

Postgres bietet zwei Befehle, die diesen Job übernehmen:

-- 1. Alle Objekte, die app_owner gehoeren, an postgres uebertragen:
REASSIGN OWNED BY app_owner TO postgres;

-- 2. Restliche Privilegien und Default-Privileges der Rolle aufraeumen:
DROP OWNED BY app_owner;

-- 3. Jetzt klappt der DROP:
DROP ROLE app_owner;

Was hier passiert:

• REASSIGN OWNED überträgt das Eigentum aller Objekte, die app_owner in der aktuellen Datenbank besitzt, an die Ziel-Rolle.
• DROP OWNED entfernt zusätzlich alle Privilegien, die der Rolle in dieser Datenbank vergeben wurden — sowohl aktive (GRANT … TO app_owner) als auch zukünftige (ALTER DEFAULT PRIVILEGES … GRANTED BY app_owner).
• Erst dann darf DROP ROLE die Rolle entfernen.

Wichtig: Beide Befehle wirken nur in der aktuellen Datenbank. Wenn die Rolle in mehreren Datenbanken Objekte besitzt, musst du dich der Reihe nach mit jeder verbinden und den Vorgang wiederholen.

Owner-Inspektion im Katalog

Wer wissen will, wem was gehört, fragt den Systemkatalog:

SELECT n.nspname AS schema, c.relname AS object,
       pg_get_userbyid(c.relowner) AS owner, c.relkind
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname NOT IN ('pg_catalog','information_schema')
  AND c.relkind IN ('r','p','v','m','S')
ORDER BY 1, 2;

relkind zeigt: r = ordentliche Tabelle, p = partitionierte Tabelle, v = View, m = Materialized View, S = Sequence.

Für Schemas direkt:

SELECT nspname AS schema, pg_get_userbyid(nspowner) AS owner
FROM pg_namespace
WHERE nspname NOT LIKE 'pg_%' AND nspname <> 'information_schema';

Weiterführende Ressourcen

Externe Quellen

• Database Roles – Object Ownership
• REASSIGN OWNED – PostgreSQL Documentation
• DROP OWNED – PostgreSQL Documentation
• ALTER TABLE … OWNER TO
• Dropping Roles – PostgreSQL Documentation

Verwandte Artikel

• Rollen und Privilegien — Übersicht
• GRANT/REVOKE — Grundlagen
• Benutzer-Rolle entfernen
• Datenbank umbenennen und Owner wechseln