User Tools

Site Tools


wiki:postgres:pg_tune_kurs_permissions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

wiki:postgres:pg_tune_kurs_permissions [2017/09/28 12:21] (current)
Line 1: Line 1:
 +====== Permissions ======
 +
 +**Connections und Authentifizierung**\\
 +
 +**Ohne Änderung der Einstellungen für die Rolle public ist die ganze Permissions-Geschichte ziemlich sinnlos,** da die Rolle //public// folgende Voreinstellungen hat:\\
 +  - Connect-Rechte auf die Datenbank
 +  - Create- und Usage-Rechte auf das Schema //public//
 +\\
 +
 +**Die höchste Sicherheit wird erreicht, wenn die Datenbank auf nichts hört.** Dies kann man erreichen indem man in **postgresql.conf** //​listen_addresses = '​localhost'//​ (oder IP-Adresse des DB-Servers) setzt. Bei einem Hot Standby Server muß man hier jedoch die IP-Adresse des Slaves angeben.\\
 +\\
 +===== 7 Ebenen von Permissions =====
 +
 +  - listen_addresses
 +  - pg_hba_conf
 +  - LOGIN oder NOLOGIN
 +--------------------------------------------bis hierher eine Sache der Instanz
 +  - Connect zur Datenbank
 +  - Schema Rechte
 +  - Tabellen Rechte
 +  - Spalten Rechte
 +
 +===== Host based Access Control (pg_hba.conf) =====
 +Hans: **"​Rassisten Setting"​**\\
 +
 +  - local
 +  - host
 +  - hostssl
 +  - hostnossl
 +
 +**Abhängig vom IP-range kann man unterschiedliche Verschlüsselungen angeben:**
 +  * md5 ... verschlüsselt
 +  * kerberos ... verschlüsselt und zentral
 +\\
 +Die erste Regel (pg_hba.conf von oben gelesen) die trifft gilt. Wenn pg_hba.conf geändert wird reicht ein //reload// - die Änderung gilt dann für neue Authentifizierungen (nicht für jene die gerade mit der Datenbank verbunden (connected) sind.
 +
 +===== LOGIN oder NOLOGIN =====
 +**CREATE ROLE und CREATE USER ist dasselbe** (nur damit nicht in irgendeiner blöden Zeitschrift dann gesagt wird, daß PostgreSQL keine //user// kennt wurde //user// behalten.\\
 +**Rollen / User sind beliebig tief ineinander schachtelbar.**\\
 +
 +NOLOGIN für abstrakte Rollen verwenden:​\\
 +Beispiel:
 +NOLOGIN Rolle  buchhalter erbt Rechte von den\\
 +NOLOGIN Rollen buchhaltung_lesen und buchhaltung_schreiben\\
 +NOLOGIN Rolle  controller erbt Rechte von buchhaltung_lesen\\
 +------------------------------------------------------------\\
 +LOGIN   User Karl ist controller (erbt von Rolle controller)\\
 +LOGIN   User Paul ist buchhalter (erbt von Rolle buchhalter)\\
 +Der Vorteil davon liegt in der einfacheren Rechteverwaltung,​ da physische Personen öfter wechseln als abstrakte Rollen.
 +
 +===== Connect =====
 +Zu welcher Datenbank in einer Instanz darf sich der //user// verbinden (connect).
 +
 +===== GRANT CREATE DATABASE ... ===== 
 +Benutzer darf Schemata erzeugen.\\
 +**Instanz > Database > Schema > Tabelle > Spalte**
 +
 +===== GRANT CREATE SCHEMA ​ ===== 
 +Benutzer darf im Schema Tabellen anlegen.\\
 +
 +==== GRANT REFERENCES ==== 
 +Wenn z.B. Referenz auf andere Tabelle (über Fremdschlüssel),​ die der User nicht sehen darf (z.B. //user// darf nur Krankheiten sehen, aber nicht welcher Patient welche Krankheit hat). //user// sieht dann nur den Fremdschlüssel (z.b. 4711) aber nicht den dahinterstehenden Namen (in der z.b. Personen-Tabelle.
 +
 +==== GRANT ... ON ALL IN SCHEMA/etc. ==== 
 +Kann damit Berechtigungen z.b. für alle Tabellen in z.b. einem Schema setzen.
 +  test=# \h GRANT
 +
 +==== Rechte auf eine Tabelle anzeigen lassen ==== 
 +
 +  test=# \z t_test
 +
 +==== WITH GRANT OPTION ==== 
 +Zum **Sub-Admins** züchten.\\
 +Wenn man dem "​Sub-Admin"​ die Rechte entzieht so verlieren auch alle //user// denen der "​Sub-Admin"​ Rechte gegeben hat diese Rechte.
 +
 +
  
wiki/postgres/pg_tune_kurs_permissions.txt · Last modified: 2017/09/28 12:21 (external edit)