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.
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.
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
User-Spezifische Views (über search path). Das kann man sogar machen ohne dass es die Anwendung mitkriegt wenn der Search Path korrekt gesetzt ist.
Nur Zugriffe über Funktionen erlauben
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.
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.
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 .
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.