Der erstellte Benutzer kann ohne Berechtigungen auf alle Datenbanken in PostgreSQL zugreifen

44

Ich muss etwas in Bezug auf die Einrichtung von PostgreSQL fehlen. Ich möchte mehrere Datenbanken und Benutzer erstellen, die voneinander isoliert sind, sodass ein bestimmter Benutzer nur auf die von mir angegebenen Datenbanken zugreifen kann. Soweit ich jedoch feststellen kann, hat jeder erstellte Benutzer Zugriff auf alle Datenbanken, ohne dass bestimmte Berechtigungen erteilt wurden.

Folgendes mache ich auf einem Ubuntu Server 12.04:

  1. apt-get install postgresql
  2. sudo -u postgres createuser -DRSP mike1 (Geben Sie das Kennwort für den neuen Benutzer an.)
  3. sudo -u postgres createdb data1
  4. psql -h localhost -U mike1 data1 (Geben Sie das Kennwort an, mit dem sich der Benutzer mike1 anmelden soll.)

Es scheint, dass der neue Benutzer "mike1" kein Problem damit hat, eine Verbindung mit der Datenbank "data1" herzustellen und Tabellen usw. zu erstellen Besitzer in Schritt 3). Ist das wirklich so, wie es funktionieren soll?

Ich möchte mike1 den vollständigen Zugriff auf data1 gewähren und dies dann für weitere Benutzer und Datenbanken wiederholen, um sicherzustellen, dass die Benutzer nur auf eine (oder möglicherweise mehrere) Datenbanken meiner Wahl zugreifen können.

postgresql permissions Mikrofonplatte
quelle
1
Beachten Sie, dass ein Benutzer auch dann, wenn er auf eine Datenbank beschränkt ist, die globalen Tabellen abfragen kann, um die Liste der Datenbanknamen und die Liste der Benutzer anzuzeigen.
Freitag,

Antworten:

47

Auf SQL-Ebene kann sich jeder Benutzer tatsächlich mit einer neu erstellten Datenbank verbinden, bis der folgende SQL-Befehl ausgegeben wird:

REVOKE connect ON DATABASE database_name FROM PUBLIC;

Sobald dies erledigt ist, muss jedem Benutzer oder jeder Rolle, die eine Verbindung herstellen können soll, explizit die Berechtigung connect erteilt werden:

GRANT connect ON DATABASE database_name TO rolename;

Bearbeiten: In einem Szenario mit mehreren Mandanten connectwürde mehr als nur das Privileg entfernt. Tipps zu Mandantenfähigkeit und bewährten Methoden finden Sie im öffentlichen Wiki von postgresql: Shared Database Hosting und Verwalten von Rechten in PostgreSQL .

Daniel Vérité
quelle
Der Standard sollte umgekehrt sein. Ich möchte einen Benutzer mit einem zufällig generierten Kennwort erstellen und ihm Zugriff auf eine einzelne postgresDatenbank gewähren, in dem Wissen, dass auf alle Datenbanken zugegriffen werden kann.
TheRealChx101
24

PUBLIC hat standardmäßig Zugriff auf die Datenbank, kann jedoch nicht auf die Daten zugreifen. Sie können die ÖFFENTLICHKEIT WIDERRUFEN:

REVOKE CONNECT ON DATABASE your_database FROM PUBLIC;

Wenn Sie diese Einstellung für alle zukünftigen Datenbanken wünschen, widerrufen Sie CONNECT für die Datenbank template1 (Standardvorlagendatenbank zum Erstellen einer neuen Datenbank):

REVOKE CONNECT ON DATABASE template1 FROM PUBLIC;
Frank Heikens
quelle
Aha. Jetzt macht es mehr Sinn. Ich sollte wohl nicht als PostgreSQL-Neuling hierher kommen und darüber streiten, dass PUBLIC möglicherweise nicht standardmäßig das CONNECT-Privileg für template1 haben sollte :) Aber jetzt sehe ich auch, dass die Daten nie in Gefahr waren. Vielen Dank!
mikeplate
1
Sie sind als Neuling mehr als willkommen, auch um Einstellungen zu bestreiten. Daraus kann jeder lernen!
Frank Heikens
1
Tatsächlich wird dieses CONNECT-Privileg nicht von der Vorlage an die neue Datenbank übergeben, sodass das Widerrufen der Berechtigung für template1 nicht den genannten Effekt hat.
Daniel Vérité,
2
@ DanielVérité Ich verstehe. Daher denke ich, dass die Lösung darin besteht, sich beim Erstellen einer neuen Datenbank immer an REVOKE CONNECT zu erinnern und dies zu tun. Ist das wirklich so, wie es normalerweise von PostgreSQL-Administratoren gemacht wird, oder sollte es mich nicht so sehr interessieren, da auf die Daten sowieso nicht zugegriffen werden kann? Dennoch denke ich, dass eine Liste von Tabellen möglicherweise unnötige Informationen für zukünftige Angriffe preisgibt, wenn auch nur zwischen bereits autorisierten Benutzern in einer Umgebung mit mehreren Mandanten. Außerdem: Ich habe gerade festgestellt, dass public in jeder Datenbank, die noch nicht REVOKE CONNECT war, auch eigene Tabellen erstellen kann. Fühlt sich ein bisschen komisch an, als Standard zu haben, muss ich sagen.
mikeplate
1
Ja. Ich füge meiner Antwort verwandte Links hinzu. Vielleicht möchten Sie ein paar weitere Dokumente dazu lesen.
Daniel Vérité
4

Die andere Ebene, auf der Sie den Zugriff steuern können, ist die Datei pg_hba.conf.

Sie können herausfinden, wo die Datei gespeichert ist mit:

SHOW hba_file;

Wenn Sie sich für diesen Mechanismus entscheiden, gibt es eingebettete Kommentare, die möglicherweise ausreichen, um Ihnen den Einstieg zu erleichtern. Die Dokumente sind hier:

http://www.postgresql.org/docs/current/interactive/auth-pg-hba-conf.html

kgrittn
quelle
Vielen Dank! Ich habe mir die Datei pg_hba.conf angesehen, aber ich hatte den Eindruck, dass sie nur regelt, wie sich ein Benutzer authentifiziert, wenn er eine Verbindung zu einer Datenbank herstellt, und nicht, welche Berechtigungen der Benutzer in derselben Datenbank hat.
mikeplate
1
Ein Benutzer kann nur eine Verbindung zu Datenbanken herstellen, wie dies in der Datei pg_hba.conf zulässig ist. Dazu gehören nicht nur die Kombination aus Benutzer und Datenbank, sondern auch der Host, von dem aus die Verbindung hergestellt wird, und die zulässige Authentifizierungsmethode. Wenn Sie diese Granularität der Steuerung nicht benötigen, ist die in anderen Antworten beschriebene GRANT/ REVOKE-Technik wahrscheinlich einfacher. Zum einen benötigen Sie dafür lediglich eine Superuser-Datenbankverbindung, zum anderen benötigen Sie ein Betriebssystem-Login, mit dem Sie die Datei bearbeiten können.
Freitag,
0

Ich bin auf diesen Thread gestoßen, um zu verhindern, dass Benutzer die anderen Datenbanknamen auflisten. Das REVOKE CONNECTverhindert das nicht.

Wie aus den Antworten auf diese SO-Frage hervorgeht, gibt es keinen (empfehlenswerten) Weg, dies zu erreichen.

AdamAL
quelle