mich beschäftigt gerade folgendes Thema. Ich durchsteige gerade das Rechtekonzept und mir ist aufgefallen, dass der Ottonormalnutzer, sobald er erzeugt wurde, folgende Privilegien besitzt. Er darf einfach mal in der postgres-DB User-Tabellen erzeugen. Nun habe ich jedoch die Doku zu rate gezogen und da steht, dass die Default-acl so gestrickt wurde, dass das eigentlich nicht gehen soll. Daher bin ich auf die glorreiche Idee gekommen, dass ich folgendes sage:
REVOKE CREATE ON SCHEMA public from public; -- für die DB postgres
Und jetzt meine Frage. Laufe ich ins Chaos oder betrifft es einzig die Erzeugung von User-Tabellen in postgres??
PostgreSQL ist (leider) nicht wirklich z.B. für Shared Hosting zugeschnitten. Das man es dennoch so verwenden kann, und wie, hat mein Kollege vor Jahren mal hier dokumentiert:
@ads: ein sehr guter Einwurf. Den hatte ich bereits verdrängt.
@akretschmer: Die Frage wurde mir eigentlich damit beantwortet. Quasi verstehe ich das so, dass ich die Schritte (die Revoke’s) aus dem geposteten Link für template1 und postgres machen sollte. Stellt sich für mich noch die Frage, ob man das nicht auch für template0 machen könnte? Quasi um die ganze Riege der Datenbanken von vorne herein nen bisschen sicherer zu machen. Nebenbei wüsste ich gern, warum als Default “public” immer auch in neue Dbs schreiben kann (zumindest bei mir). Muss ich dazu die Default-ACLs anpassen?
Jeder Benutzer darf genau das, was in “template1” an Rechten festgelegt ist.
Wenn du das in “template1” anpasst, bekommt jede neue Datenbank diese Rechte als Kopie.
besten Dank für die Antwort. Ich war mal so frei und habe folgendes gemacht.
mit template1 verknüpfen
revoke all on database template1 from public;
revoke all on schema public from public;
grant all on schema public to postgres;
Dann habe ich einfach eine neue Datenbank erzeugt mit Namen und nem Eigentümer mit Namen .
Sofern ich mich jetzt mit einem alternativen Nutzer mit z.B. Namen anmelde komme ich auf die DB rauf, kann aber nichts erstellen. Ds ist schon mal sehr gut. Mich stört jetzt jedoch noch, dass der Nutzer sich überhaupt verbinden darf.
Dieses Problem hab ich gelöst indem ich in der DB halt nochmal ein ‘REVOKE ALL ON DATABASE test FROM public’ losgelassen habe.
Und nun meine Frage. Ich dachte, dass der Punkt 2 den DB-Zugriff von vorne herein totlegt und man nicht abermals nochmal ran muss.
Oder bin ich auf einem ganz falschen Weg und hab das ganze nicht verstanden? Kann ja auch gut möglich sein.
Gruß und besten Dank schon mal für eine mögliche Antwort.
Datei wurde mehrfach gelesen. Mich interessiert halt nur dieses Verhalten, da mir in einer PSQL-Schulung freude strahlend mitgeteilt wurde, dass man doch lieber die Berechtigung per REVOKE/GRANT setzen soll, statt die pg_hba-Datei aufzublähen. Und wenn ich die Doku richtig lese, wird halt auch explizit darauf hingewiesen.
Ich weiß jetzt leider nicht, was ich da falsches gesagt habe. Aber auf die Gefahr hin, noch irgendwas anderes inkorrekt zu schreiben, beende ich das Thema und bedanke mich trotzdem. Zumindest komme ich zu dem Schluss, dass jeder eine andere Meinung hat, wie man am besten die Zugriffsbeschränkung gestaltet.
Also - ich würde gerne diesen Threat nochmal aufleben lassen, da er Potential und Informationsgehalt hat:
Regelmäßige Änderungen in der pg_hba.conf sollte man verhindern, weil jeweils ein Dienststart von Nöten ist, bevor die neue Regeln greifen und das ist in produktiver Umgebung nicht so einfach möglich. Aber es sollte anders gehen…
Ich baue mir gerade eine pg_hba.conf zusammen, die generelle Zugriffsregeln definiert und vielleicht anderen Interessenten hilfreich erscheinen könnte:
Ich würde mich freuen, wenn Meinungen/Optimierungsmöglichkeiten/Fehler geäußert werden:
#host DB USER CIDR-ADDRESS METHOD # Erläuterungen
Alle lokalen Zugriff auf dem Server sollen ohne Passwortüberprüfung vertraut werden
host all all localhost trust # Alle lokalen Zugriffe
benötigt für Basebackups
host replication postgres localhost trust # regelm. lokale Basebackups
Alle Zugriffe aus unserem IPv4/6-Netz mit verschlüsselter Passwortabfrage
host all all 192.168.0.0/16 md5 # IPv4: alle Zugriffe
host all all ::1/128 md5 # IPv6: alle Zugriffe
Mein Versuch, den default-Schreibzugriff für public auf die DB “postgres” für andere zu beschränken???
host postgres postgres 192.168.0.0/16 md5 # nur mit postgres auf DB-postgres
host postgres all 192.168.0.0/16 reject # keine Zug. auf postgres-DB für andere
Hier bastel ich gerade an einer Möglichkeit, Windows-Domänenzuriffe umzusetzen (pg_ident.conf)
host postgres all 192.168.0.0/16 ident map=mpVH # Domänenzugriffe???
(Meine Umgebung: Windows Server - Postgre-SQL Vers. 9.5)
Dein Vorhaben ist grundsätzlich sehr löblich, aber wie akretschmer schon geschrieben hat, sollte hier ein Reload des Dienstes ausreichen, um die neuen Daten einzulesen. Ich gehe mal davon aus, das pg_ctl reload auch unter Windows funktioniert.
Eine generelle pg_hba.conf zu basteln ist auch eher schwierig, da jeder hier andere Netze/Namen/Wünsche und Vorgaben hat.
Einige Sachen wie Zugänge über local, Replikation und “sonstige Zugänge” kann man da bestimmt machen, aber ich glaub der Rest ist zu speziell, als das man da wirklich was groß verallgemeinern kann.
Wenn du aber ein paar spannende Kniffe findest, bin ich persönlich da gern offen, auch wenn die pg_hba.conf da glaub ich wenig potential bietet
