Überprüfen von definierten Sicherheitsrichtlinien auf Zeilenebene in PostgreSQL-9.5

Question

Ich habe das brandneue PostgreSQL-9.5 (Alpha) erstellt und bin sehr gespannt auf die neue Funktion row level security. Dies verspricht eine vielseitige Zugriffsverwaltung, die ein wenig einfacher ist.

Als Beispiel habe ich bisher ein Modell verwendet, bei dem eine NOLOGIN Rolle Besitzer 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 CREATE POLICY Befehl auf 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. (Dies alles, nachdem Tabellen und Richtlinien offensichtlich definiert wurden.) Gibt es eine einfache Möglichkeit, etablierte Richtlinien für RLS-fähige Tabellen zu identifizieren?

(Es gibt auch die lang erwartete UPSERT und viele mehr jsonb Funktionen für diejenigen, die interessiert sind, sowie viele Leistungsverbesserungen.)

Answer 1

Ok, es herausgefunden. (Geez, ist niemand mit 9.5 noch ??)

Frage 1: Welche Tabellen haben Zeilenschutz?

Die pg_class Beziehung hat eine neue Spalte relrowsecurity boolean, die so einfach ist, wie es aussieht:

SELECT oid, relname FROM pg_class WHERE relrowsecurity = 'true'; 

Frage 2: Welche Strategien auf RLS-fähigen Tabellen definiert werden?

Der Systemkatalog hat eine neue Beziehung pg_policy, die auf die Politik alle Daten speichert, und zwar den Namen der Politik, die oid der Tabelle, den Befehl es gilt, die Rollen (oid[]), an dem die Politik gilt 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 ausgewertet werden. Dies macht diesen Ansatz potenziell schneller als die Verwendung von Sichten, wie sie in der Frage ausgeführt wurden, da weniger Klauseln für jeden Aufruf analysiert und ausgewertet werden müssen.