# GRANT auf DB postgres

**URL:** https://www.pg-forum.de/t/grant-auf-db-postgres/6447
**Category:** Benutzer- & Rechteverwaltung
**Created:** [6. Juli 2012 um 15:02 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447 "2012-07-06T15:02:44Z")
**Posts on this page:** 15
**Page:** 1

<div class="post-metadata">

### Author: ![CaptnUnterhose](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/c/7feea3/32.png) [@CaptnUnterhose](https://www.pg-forum.de/u/CaptnUnterhose)
#### Post date: [6. Juli 2012 um 15:02 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/1 "2012-07-06T15:02:44Z")

</div>

Hallo werte Freude der gepflegten Datenbank,

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:

```nohighlight
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??

Gruß und Danke schon mal

CaptnUnterhose

---

<div class="post-metadata">

### Author: ![CaptnUnterhose](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/c/7feea3/32.png) [@CaptnUnterhose](https://www.pg-forum.de/u/CaptnUnterhose)
#### Post date: [6. Juli 2012 um 15:03 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/2 "2012-07-06T15:03:33Z")

</div>

Ach ja, mir ist gerade aufgefallen das der Titel eigentlich gar nicht so passt. Aber gut.

---

<div class="post-metadata">

### Author: ![akretschmer](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/a/a6a055/32.png) [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [6. Juli 2012 um 15:13 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/3 "2012-07-06T15:13:32Z")

</div>

> [@CaptnUnterhose](#):
>
> Hallo werte Freude der gepflegten Datenbank,
> 
> 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:
> 
> ```plaintext
> 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??
> 
> Gruß und Danke schon mal
> 
> CaptnUnterhose

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:

[Shared Database Hosting - PostgreSQL wiki](http://wiki.postgresql.org/wiki/Shared_Database_Hosting)  
  
  
Les das mal durch, sollte Dein Problem/Frage mit beantworten.  
  
  
Andreas

---

<div class="post-metadata">

### Author: ![ads](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/a/8e7dd6/32.png) [@ads](https://www.pg-forum.de/u/ads)
#### Post date: [8. Juli 2012 um 09:48 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/4 "2012-07-08T09:48:59Z")

</div>

Außerdem solltest du von vorne herein verhindern das sich der normale Benutzer an dieser Datenbank anmelden darf.  
Das wird in “pg\_hba.conf” geregelt.

---

<div class="post-metadata">

### Author: ![CaptnUnterhose](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/c/7feea3/32.png) [@CaptnUnterhose](https://www.pg-forum.de/u/CaptnUnterhose)
#### Post date: [9. Juli 2012 um 09:29 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/5 "2012-07-09T09:29:53Z")

</div>

Hallo miteinander,

@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?

Gruß und herzlichen Dank für eine Antwort.

Michael

---

<div class="post-metadata">

### Author: ![ads](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/a/8e7dd6/32.png) [@ads](https://www.pg-forum.de/u/ads)
#### Post date: [9. Juli 2012 um 09:34 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/6 "2012-07-09T09:34:13Z")

</div>

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.

An template0 darf sich sowieso niemand anmelden.

---

<div class="post-metadata">

### Author: ![CaptnUnterhose](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/c/7feea3/32.png) [@CaptnUnterhose](https://www.pg-forum.de/u/CaptnUnterhose)
#### Post date: [9. Juli 2012 um 10:04 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/7 "2012-07-09T10:04:17Z")

</div>

Mahlzeit,

besten Dank für die Antwort. Ich war mal so frei und habe folgendes gemacht.

1. mit template1 verknüpfen
2. revoke all on database template1 from public;
3. revoke all on schema public from public;
4. 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.

Michael

---

<div class="post-metadata">

### Author: ![ads](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/a/8e7dd6/32.png) [@ads](https://www.pg-forum.de/u/ads)
#### Post date: [9. Juli 2012 um 10:13 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/8 "2012-07-09T10:13:41Z")

</div>

Du solltest dir wirklich die pg\_hba.conf Dokumentation anschauen …

---

<div class="post-metadata">

### Author: ![CaptnUnterhose](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/c/7feea3/32.png) [@CaptnUnterhose](https://www.pg-forum.de/u/CaptnUnterhose)
#### Post date: [9. Juli 2012 um 10:49 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/9 "2012-07-09T10:49:59Z")

</div>

Mahlzeit abermals,

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.

Gruß  
Michael

---

<div class="post-metadata">

### Author: ![ads](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/a/8e7dd6/32.png) [@ads](https://www.pg-forum.de/u/ads)
#### Post date: [9. Juli 2012 um 11:04 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/10 "2012-07-09T11:04:18Z")

</div>

“aufzublähen”? Nun ja, kein Kommentar.

---

<div class="post-metadata">

### Author: ![CaptnUnterhose](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/c/7feea3/32.png) [@CaptnUnterhose](https://www.pg-forum.de/u/CaptnUnterhose)
#### Post date: [9. Juli 2012 um 11:25 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/11 "2012-07-09T11:25:12Z")

</div>

> [@ads](#):
>
> “aufzublähen”? Nun ja, kein Kommentar.

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.

So denn, Greetz und besten Dank trotzdem.

---

<div class="post-metadata">

### Author: ![Hakinen](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/h/47e85d/32.png) [@Hakinen](https://www.pg-forum.de/u/Hakinen)
#### Post date: [9. März 2016 um 13:51 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/12 "2016-03-09T13:51:47Z")

</div>

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)

---

<div class="post-metadata">

### Author: ![akretschmer](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/a/a6a055/32.png) [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [9. März 2016 um 14:00 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/13 "2016-03-09T14:00:35Z")

</div>

Änderungen der pg\_hba.conf sind nach einem Reload (kein Restart) aktiv.

---

<div class="post-metadata">

### Author: ![DaniloE](https://www.pg-forum.de/letter_avatar_proxy/v4/letter/d/73ab20/32.png) [@DaniloE](https://www.pg-forum.de/u/DaniloE)
#### Post date: [9. März 2016 um 14:09 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/14 "2016-03-09T14:09:35Z")

</div>

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 🙂

---

<div class="post-metadata">

### Author: ![system](https://www.pg-forum.de/uploads/default/original/1X/dc97a981dd26692d5fb52e8b8fc7c090d7b9559a.png) [@system](https://www.pg-forum.de/u/system)
#### Post date: [21. Februar 2021 um 06:49 UTC](https://www.pg-forum.de/t/grant-auf-db-postgres/6447/15 "2021-02-21T06:49:39Z")

</div>


