Ich habe das brandneue PostgreSQL-9.5 (alpha) gebaut und bin sehr gespannt auf die neue Funktion von Sicherheit auf Zeilenebene . Dies verspricht, das Zugriffsmanagement für mehrere Rollen ein wenig einfacher zu gestalten.
Als Beispiel habe ich bisher ein Modell verwendet, bei dem eine Rolle NOLOGIN Eigentümer der Datenbank ist und alle Tabellen, Ansichten, Funktionen usw .; und erstellen Sie dann Ansichten, um den entsprechenden Zugriff auf bestimmte Rollen zu gewähren. Alles gut und gut, aber die Ansichten wuchern. Der neue Befehl CREATE POLICY für Tabellen mit ENABLE ROW LEVEL SECURITY scheint eine sauberere Alternative zu sein, um das gleiche Ziel zu erreichen.
Bisher konnte ich jedoch nicht feststellen, welche Tabellen RLS-fähig sind und welche Richtlinien für sie definiert sind. (All dies, nachdem die Tabellen und Richtlinien offensichtlich definiert wurden.) Gibt es eine einfache Möglichkeit, etablierte Richtlinien für RLS-aktivierte Tabellen zu identifizieren?
(Es gibt auch die lang ersehnte UPSERT und viele weitere jsonb Funktionen für diejenigen von euch, die daran interessiert sind, sowie viele Leistungsverbesserungen.)
Ok, habe es herausgefunden. (Meine Güte, benutzt noch niemand 9.5?)
Frage 1: Welche Tabellen haben Sicherheit auf Zeilenebene?
Die Beziehung pg_class hat eine neue Spalte relrowsecurity boolean , die so einfach ist, wie sie aussieht:
Frage 2: Welche Richtlinien sind in RLS-aktivierten Tabellen definiert?
Der Systemkatalog hat eine neue Beziehung pg_policy , in der alle Informationen zur Richtlinie gespeichert werden, insbesondere der Name der Richtlinie, der oid der Tabelle, der Befehl, auf den sie angewendet wird, die Rollen ( oid[] ). auf die die Richtlinie angewendet wird und die USING und WITH CHECK -Klauseln.
Interessanterweise werden die letzten beiden als pg_node_tree gespeichert, die mit dem Ausführungsplan der Abfrage, die der Richtlinie unterliegt, zusammengeführt werden, so dass die Bedingung (en) der Richtlinie nicht bei jedem Aufruf neu bewertet werden. Das macht diesen Ansatz möglicherweise schneller als die Verwendung von Sichten, wie in der Frage ausgeführt, weil weniger Klauseln für jeden Aufruf analysiert und ausgewertet werden müssen.
Tags und Links postgresql postgresql-9.5