Postgres-Server: Neuen Parameter in der postgresql.conf zur Abfrage in postgres.c

Hallo,
kennt jemand ein Tutorial/eine Doku, die beschreibt wie man neue Parameter in den Server einbringen kann. Wenn im Backend eine Verbindung aufgebaut hat möchte ich prüfen ob diese Verbindung durch einen bestimmten User aufgebaut wurde. Da ich für nur für diesen, die übergebenen SQL-Queries überarbeiten muss. So wie ich das verstanden habe muss ich u. a. in der guc.c ein paar Anpassungen machen, aber im Moment ist das ein ziemlicher Schuss ins Blaue.

Danke und Gruß
Michael

Vielleicht habe ich ja irgendwas nicht verstanden, aber der User der die Verbindung aufbaut, kann durch

select current_user

abgefragt werden.

Einstellungen aus der postgresql.conf (inkl. custom options) kannst Du mit current_setting(‘foobar’) abfragen.

Ich bin gerade in der Main-Function des Backends, die wird gestartet wenn ein Client ein Login durchführt. Abhängig davon ob der User derjenige welche ist möchte ich eine dll laden an der Stelle.

Es geht darum die Queries anhand bestimmter Regeln umzubauen/einzuschränken. Bevor diese verarbeitet werden. Dies muss bei einem bestimmten User passieren, z.B. dem User einer Webanwendung. Laut Postgres-Sourcen darf man an der Stelle aber nicht auf die DB zugreifen, dass heißt der User bei dem das passieren soll muss ich anders mitteilen, ich hatte gehofft den über einen neuen Parameter im .conf-File einzupflegen. Alternativ kann ich ihn immer noch hart codiert in den Sourcen abfragen, aber einen frei bestimmbarer User fänd ich da schon eleganter.

Vielleicht kann man Custom Options direkt im Server abfragen, ich guck mal danach, danke.

Ok, mal langsam. Du denkst, das der Weg dein Problem zu lösen nur durch den Umbau der Sourcen möglich ist?

Was für ein Problem genau möchtest du lösen?

Hast du über all die damit einhergehenden Probleme nachgedacht? Support deiner Änderungen in zukünftigen Major- und Minor Releases, z. B.?

Vielleicht sagst Du uns mal was Du wirklich vorhast. Was genau ist das Problem.

Ich kann mir da ein paar Lösungen vorstellen, die ohne “hacken” im Postgres Code auskommen

  1. User-Spezifische Views (über search path). Das kann man sogar machen ohne dass es die Anwendung mitkriegt wenn der Search Path korrekt gesetzt ist.
  2. Nur Zugriffe über Funktionen erlauben
  3. möglicherweise geht es auch über RULEs aber dazu müsste man wissen was ihr eigentlich ändern wollt.

Ein Änderung des PostgreSQL Source führt aber mit hoher Wahrscheinlichkeit zu einem unwartbaren System. Ich persönlich würde 2) vorziehen, 1) lässt sich möglicherweise leichter “unterschieben”. Beide Lösungen sind aber sicherlich leichter zu implementieren als ein Hack im Postgres Core (den ihr bei jedem Update dann auch noch nachziehen müsst).

Wie gesagt: wenn Du das eigentliche Problem schilderst, kann man vielleicht ein bessere Lösung finden.

Ich gebe der Query einen Parameter mit, eine eindeutige SitzungID für den Benutzer einer Webanwendung, und nutze den in meiner umgebauten Query (das Konzept nennt sich parameterisierte Views) um die Daten nach diesem Parameter einzuschränken, und das soll eben nur bei einem bestimmten DB-User passieren.

Mir ist schon klar, dass dies nicht ohne weiteres in jedem neuen Release drin sein wird, aber es geht mir hier hauptsächlich darum ob und wie das machbar ist.

Rules geben das leider nicht her. Über Funktionen läßt sich das realisieren (wurde hier glaub ich auch schon mal diskutiert), aber ich soll es nun mal so versuchen (ausserdem wären Funktionen schon einmal Teil eines anderen Projekts). User-Specified Views sagen mir jetzt nichts aber es klingt nach speziellen Views je DB-User. Aber bei Web-Anwendungen liegt ja genau da das Problem.

Es handelt sich hier auch um ein Projekt an einer FH, nicht um ein konkretes Produkt.

Benutzt ihr ein Framework? Wenn ja, welches. IMHO ist es Sache der jeweiligen Session, anhand von definierten Permissions die Daten bereitzustellen, die ein eingeloggter Nutzer sehen darf. Die Datenbank selbst hat mit den Webnutzern nix zu tun. Vielleicht habe ich aber auch dein Problem nicht verstanden.

Gruß Uwe

Nein kein Framework, die Datenbank soll nur die Daten zurückgeben die für eine bestimmte ID u. den dahinter stehenden User freigegeben sind.

So, du sprichst also von row-based security?

Ja in die Richtung geht es (bei uns heißt das fine grained access control). Das View steuert die Spalten die der User sehen darf, der Rewrite die Zeilen.

Ich versuche komplett CRUD abzubilden. Aber eben ohne Functions oder Views die nur für die eine Session generiert werden. Grad mit Functions läuft es ja darauf raus dass man dann für jede Operation eine Function schreiben muss.

Schau Dir Veil oder SEPostgreSQL Introduction - PostgreSQL wiki an.


Andreas

Ja und?
Das ist doch genau das was eine API macht - “Aufrufe” für “Business-Funktionen” zur Verfügung zu stellen.

Da gibt es eine Firma in Australien, die stellen “Data Chamber” her. Auch so eine Lösung.

Aber wenn du das wirklich in PG integrieren möchtest: ich empfehle dir dringend, das erst mal auf der PostgreSQL Hackers Mailingliste zu diskutieren.
Ich bin mir sicher, das du Dutzende Aspekte übersiehst, wenn du einfach nur drauf los programmierst.

Data Chambers ist ja erstmal Systemunabhängig zum. laut deren Homepage, also nicht Postgresspezifisch.

Veil setzt beim Starten der Session einen User und der wird dann verwendet für die Dauer der Session. Der Ansatz ist nett, nicht dass was ich machen soll, aber nett.
Und SE scheint die FGAC auf DB-User Ebene anzusetzten. Für mich also nicht praktikabel :frowning: .

Wie gesagt es gibt bereits Projekte bzw. auch Forschungsarbeiten bei mir an der FH die die Zugriffskontrolle über Functionen abbilden oder eben Views auf die nur mit der Session-ID zugriffen werden kann.

Mein Eingriff in den Server ist aber eher minimal, beim Starten der Verbindung lade ich die eine dll mit meiner Funktion und übergebe an diese die Query, die überarbeitete Query wird dann weiter verarbeitet. Das funktioniert im Übrigen auch schon tadellos.
Jetzt würde ich das ganze halt noch gerne von einem bestimmten DB-User abhängig machen.