Wie verwalte ich DEFAULT PRIVILEGES für USER auf einer DATABASE vs SCHEMA?

Ich möchte eine relativ einfache, interne, datenbankgesteuerte Anwendung von SQLite3 auf PostgreSQL 9.3 migrieren und die Berechtigungen in der Datenbank nach und nach verschärfen.

Die Anwendung besteht derzeit aus einem Befehl zum Aktualisieren der Daten. und eine, um es abzufragen. Natürlich muss ich die Datenbank auch auf andere Weise pflegen (neue Tabellen, Ansichten, Trigger usw. erstellen).

Während diese Anwendung zunächst die einzige ist, die auf dem Server gehostet wird, gehe ich lieber davon aus, dass sie in Zukunft möglicherweise auf einem Server mit anderen Datenbanken gehostet wird, anstatt später verschlüsselt zu werden, wenn dies in erforderlich wird die Zukunft.

Ich würde denken, dass dies ein ziemlich häufiger Satz von Anforderungen ist, aber ich habe Probleme, ein einfaches Tutorial zu finden, in dem erklärt wird, wie eine neue Datenbank in PostgreSQL mit dieser Art der Trennung von Benutzern und Berechtigungen eingerichtet wird. Die Referenzen beziehen sich ausführlich auf Gruppen, Benutzer, Rollen, Datenbanken, Schemata und Domänen. aber ich finde sie verwirrend.

psqlFolgendes habe ich bisher ausprobiert (von innen als 'postgres'):

CREATE DATABASE hostdb;
REVOKE ALL ON DATABASE hostdb FROM public;
\connect hostdb
CREATE SCHEMA hostdb;
CREATE USER hostdb_admin WITH PASSWORD 'youwish';
CREATE USER hostdb_mgr   WITH PASSWORD 'youwish2';
CREATE USER hostdb_usr WITH PASSWORD 'youwish3';

GRANT ALL PRIVILEGES ON DATABASE hostdb TO hostdb_admin;
GRANT CONNECT ON DATABASE hostdb TO hostdb_mgr, hostdb_usr;
ALTER DEFAULT PRIVILEGES IN SCHEMA hostdb GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO hostdb_mgr;
ALTER DEFAULT PRIVILEGES IN SCHEMA hostdb GRANT SELECT ON TABLES TO hostdb_usr;

Aber ich bekomme nicht die beabsichtigte Semantik. Ich möchte es so konfiguriert haben, dass nur die hostdb_adminTabellen erstellen (und löschen und ändern) können; das hostdb_mgrlesen kann, einfügen, aktualisieren und löschen auf alle Tabellen standardmäßig; und der hostdb_usrkann nur alle Tabellen (und Views) lesen.

Als ich das versuchte, stellte ich fest, dass ich Tabellen in hostdbjedem dieser Benutzer erstellen konnte . Ich konnte jedoch für jeden Benutzer nur die von diesem Benutzer erstellten Tabellen lesen oder ändern - es sei denn, ich verwende eine explizite GRANT.

Ich vermute, dass zwischen CREATE DATABASEund etwas fehlt CREATE SCHEMA, um das SCHEMAauf das anzuwenden DATABASE?

(Wenn die Dinge weiter fortgeschritten sind, werde ich auch Fragen haben, um ähnliche Einschränkungen für TRIGGERSgespeicherte Prozeduren VIEWSund möglicherweise andere Objekte anzuwenden .)

Wo finde ich eine anständige Anleitung, ein Tutorial oder eine Videoserie dazu?

Wo finde ich eine anständige Anleitung, ein Tutorial oder eine Videoserie dazu?

Sie finden alles im Handbuch. Links unten.
Zugegeben, die Angelegenheit ist nicht trivial und manchmal verwirrend. Hier ist ein Rezept für den Anwendungsfall:

Rezept

Ich möchte es so konfiguriert haben, dass nur die hostdb_adminTabellen erstellen (und löschen und ändern) können;
das hostdb_mgrlesen kann, einfügen, aktualisieren und löschen auf alle Tabellen standardmäßig;
und der hostdb_usrkann nur alle Tabellen (und Views) lesen.

Als Superuser postgres:

CREATE USER schma_admin WITH PASSWORD 'youwish';
-- CREATE USER schma_admin WITH PASSWORD 'youwish' CREATEDB CREATEROLE; -- see below
CREATE USER schma_mgr   WITH PASSWORD 'youwish2';
CREATE USER schma_usr   WITH PASSWORD 'youwish3';

Wenn Sie einen leistungsstärkeren Administrator wünschen, der auch Datenbanken und Rollen verwalten kann, fügen Sie die Rollenattribute CREATEDBundCREATEROLE höher hinzu.

Weisen Sie jede Rolle der nächsthöheren Ebene zu, sodass alle Ebenen mindestens die Berechtigungen der nächst niedrigeren Ebene "erben" (kaskadieren):

GRANT schma_usr TO schma_mgr;
GRANT schma_mgr TO schma_admin;

CREATE DATABASE hostdb;
REVOKE ALL ON DATABASE hostdb FROM public;  -- see notes below!

GRANT CONNECT ON DATABASE hostdb TO schma_usr;  -- others inherit

\connect hostdb  -- psql syntax

Ich benenne das Schema schma( hostdbwas nicht verwirrend wäre). Wähle einen beliebigen Namen. Optional macht schma_adminden Besitzer des Schemas:

CREATE SCHEMA schma AUTHORIZATION schma_admin;

SET search_path = schma;  -- see notes

ALTER ROLE schma_admin IN DATABASE hostdb SET search_path = schma; -- not inherited
ALTER ROLE schma_mgr   IN DATABASE hostdb SET search_path = schma;
ALTER ROLE schma_usr   IN DATABASE hostdb SET search_path = schma;

GRANT USAGE  ON SCHEMA schma TO schma_usr;
GRANT CREATE ON SCHEMA schma TO schma_admin;

ALTER DEFAULT PRIVILEGES FOR ROLE schma_admin
GRANT SELECT                           ON TABLES TO schma_usr;  -- only read

ALTER DEFAULT PRIVILEGES FOR ROLE schma_admin
GRANT INSERT, UPDATE, DELETE, TRUNCATE ON TABLES TO schma_mgr;  -- + write, TRUNCATE optional

ALTER DEFAULT PRIVILEGES FOR ROLE schma_admin
GRANT USAGE, SELECT, UPDATE ON SEQUENCES TO schma_mgr;  -- SELECT, UPDATE are optional 

Für and drop and altersiehe Hinweise unten.

Wenn die Dinge weiter fortgeschritten sind, werde ich auch Fragen haben, um ähnliche Einschränkungen für TRIGGERSgespeicherte Prozeduren VIEWSund möglicherweise andere Objekte anzuwenden .

Ansichten sind etwas Besonderes. Für einen:

... (Beachten Sie jedoch, dass ALL TABLESAnsichten und Fremdtabellen berücksichtigt werden).

Und für aktualisierbare Ansichten :

Beachten Sie, dass der Benutzer, der das Einfügen, Aktualisieren oder Löschen in der Ansicht ausführt, über die entsprechenden Berechtigungen zum Einfügen, Aktualisieren oder Löschen in der Ansicht verfügen muss. Darüber hinaus muss der Eigentümer der Ansicht über die entsprechenden Berechtigungen für die zugrunde liegenden Basisbeziehungen verfügen, der Benutzer, der das Update ausführt, benötigt jedoch keine Berechtigungen für die zugrunde liegenden Basisbeziehungen (siehe Abschnitt 38.5 ).

Trigger sind auch etwas Besonderes. Sie benötigen das TRIGGERPrivileg für den Tisch und:

• Welche Berechtigungen sind erforderlich, um eine Triggerfunktion in PostgreSQL 8.4 auszuführen?

Aber wir weiten den Umfang dieser Frage bereits übermäßig aus ...

Wichtige Notizen

Eigentum

Wenn Sie zulassen möchten schma_admin(allein) fallen zu lassen und alte Tabellen machen die Rolle besitzt alle Objekte. Die Dokumentation:

Das Recht, ein Objekt zu löschen oder seine Definition in irgendeiner Weise zu ändern, wird nicht als gewährbares Privileg behandelt. Es ist dem Eigentümer inhärent und kann weder gewährt noch widerrufen werden. (Ein ähnlicher Effekt kann jedoch erzielt werden, indem die Mitgliedschaft in der Rolle, der das Objekt gehört, gewährt oder widerrufen wird (siehe unten). Der Eigentümer verfügt implizit auch über alle Berechtigungsoptionen für das Objekt.

ALTER TABLE some_tbl OWNER TO schma_admin;

Oder erstellen Sie zunächst alle Objekte mit der Rolleschma_admin, dann müssen Sie den Eigentümer nicht explizit festlegen. Es vereinfacht auch Standardprivilegien, die Sie dann nur für die eine Rolle festlegen müssen:

Bereits vorhandene Objekte

Standardberechtigungen gelten nur für neu erstellte Objekte und nur für die bestimmte Rolle, mit der sie erstellt wurden. Sie möchten die Berechtigungen auch für vorhandene Objekte anpassen :

• Berechtigung für Relation <Tabelle> verweigert

Gleiches gilt, wenn Sie Objekte mit einer Rolle erstellen, die nicht DEFAULT PRIVILEGESfestgelegt wurde, wie z postgres. B. der Superuser . Umhängen Eigentum schma_adminund Set Privilegien manuell - oder Set DEFAULT PRIVILEGESfür postgresals auch (während auf der rechten Seite DB verbunden!):

ALTER DEFAULT PRIVILEGES FOR ROLE postgres GRANT ...  -- etc.

Standardprivilegien

Ihnen fehlte ein wichtiger Aspekt des ALTER DEFAULT PRIVILEGESBefehls. Dies gilt für die aktuelle Rolle, sofern nicht anders angegeben:

• Standardberechtigungen können nicht geändert werden

Standardberechtigungen gelten nur für die aktuelle Datenbank. Sie können sich also nicht mit anderen Datenbanken im DB-Cluster anlegen. Die Dokumentation:

für alle in der aktuellen Datenbank erstellten Objekte

Möglicherweise möchten Sie auch Standardberechtigungen für FUNCTIONSund festlegen TYPES(nicht nur TABLESund SEQUENCES), diese sind jedoch möglicherweise nicht erforderlich.

Standardprivilegien für PUBLIC

Standardprivilegien, die gewährt werden, PUBLICsind rudimentär und werden von einigen überschätzt. Die Dokumentation:

PostgreSQL gewährt Standardprivilegien für einige Objekttypen PUBLIC. Standardmäßig werden keine Berechtigungen PUBLICfür Tabellen, Spalten, Schemas oder Tablespaces erteilt . Für andere Typen gelten die folgenden Standardberechtigungen PUBLIC: CONNECTund CREATE TEMP TABLEfür Datenbanken; EXECUTEPrivileg für Funktionen; und USAGE Privileg für Sprachen.

Meine kühne Betonung. Normalerweise reicht der obige Befehl aus, um alles abzudecken:

REVOKE ALL ON DATABASE hostdb FROM public;

Insbesondere werden keine Standardberechtigungen PUBLICfür neue Schemas erteilt . Es kann verwirrend sein, dass das Standardschema mit dem Namen "public" mit ALLBerechtigungen für beginnt PUBLIC. Dies ist nur eine praktische Funktion, um den Start mit neu erstellten Datenbanken zu erleichtern. Andere Schemata sind davon in keiner Weise betroffen. Sie können diese Berechtigungen in der Vorlagendatenbank widerrufen. template1Dann werden alle neu erstellten Datenbanken in diesem Cluster ohne sie gestartet:

\connect template1
REVOKE ALL ON SCHEMA public FROM public;

Das Privileg TEMP

Da wir alle Berechtigungen hostdbvon aufgehoben haben PUBLIC, können reguläre Benutzer nur dann temporäre Tabellen erstellen, wenn wir dies ausdrücklich zulassen. Möglicherweise möchten Sie Folgendes hinzufügen oder nicht:

GRANT TEMP ON DATABASE hostdb TO schma_mgr;

search_path

Vergessen Sie nicht, das einzustellen search_path. Wenn Sie nur eine Datenbank im Cluster haben, können Sie einfach die globale Standardeinstellung festlegen postgresql.conf. Andernfalls wird es (wahrscheinlicher) als Eigenschaft der Datenbank festgelegt oder nur für beteiligte Rollen oder sogar für die Kombination aus beiden. Einzelheiten:

• Wie beeinflusst der Suchpfad die Bezeichnerauflösung und das „aktuelle Schema“?

Möglicherweise möchten Sie dies festlegen, schma, publicwenn Sie auch das öffentliche Schema verwenden, oder sogar (mit geringerer Wahrscheinlichkeit) $user, schma, public...

Eine Alternative wäre die Verwendung des Standardschemas "public", das mit Standardeinstellungen für funktionieren sollte, search_pathsofern Sie dies nicht geändert haben. Denken Sie PUBLICin diesem Fall daran, die Berechtigungen für zu widerrufen .

verbunden

• Gewähren Sie Berechtigungen für eine bestimmte Datenbank in PostgreSQL
• PostgreSQL-DB-Benutzer dürfen nur Funktionen aufrufen