Fragen zu Speicherverwaltung einer UDF in C

Hallo UDF Spezialisten,

mir geht es grob gesagt darum, eine Set an kryptografischen Funktionen in einer in C geschriebenen DLL zu erstellen. Letztendliches Ziel ist es mit einer der Funktionen der DLL eine kryptografische Operation durchzuführen, die ein Geheimnis benötigt. Dieses Geheimnis soll pro Connection erhalten bleiben und kann der Funktion aus u.g. Gründen nicht als Parameter mitgegeben werden.

Dieses Geheimnis soll der DLL zuvor mittels Aufruf einer oder mehrerer anderer Funktionen der DLL übermittelt werden. Grund: Das Absichern der Verbindung mittels SSL hilft wenig, da das Ausführen von SQL Statements auf Grund des SQL Logs immer als Kommunikation über einen unsicheren Übertragungsweg angesehen werden muss. Daher könnte die Übermittlung des Geheimnisses z.B. durch einen einfachen Diffie-Hellman-Keyexchange passieren, den man über Aufrufe anderer Funktionen der DLL realisiert. Die Zwischenschritte des DH KeyEx als auch das schlussendlich übermittelte Geheimnis müssen somit der DLL pro Connection verfügbar bleiben. Anderen Connections darf das Geheimnis nicht zur Verfügung stehen.

Ein kapseln und verwenden von vorhandenen Mitteln wie set_config(…,true) scheint mir nicht möglich, da lokale gesetzte Parameter pro Transaktion erhalten bleiben, aber nicht pro connection. Oder?

Bei diesen theoretischen Anforderungen haben sich mir folgende Fragen gestellt:

  • Welcher PostgreSQL Prozess lädt eigentlich die DLL? Der Prozess der jeweiligen Connection? (Wäre gut, sonst würde eine Isolation pro Connection schwierig)
  • Ist es überhaupt möglich unter der Benutzung von palloc() den allokierten Speicher wie gewünscht zu verwenden? (Zwischenspeichern verschiedeneren Berechnungen, speichern eines Geheimnisses = funktionsübergreifende Speichernutzung innerhalb der DLL?)
  • Ist sowas beim Speichermanagement von Postgres generell, vielleicht anderweitig, vorgesehen?
  • Hat jemand schon einmal etwas ähnliches gemacht, bzw. einen weniger komplexen Weggefunden, um obiges zu erreichen?

LG

ich bin nicht der Programmerer, aber local_preload_libraries : “Lists unprivileged shared libraries to preload into each backend.”

Es gibt übrigens eine pg_crypto - Extension. Möglicherweise ist das Read nicht neu zu erfinden.

local_preload_libraries rentiert sich zu recherchieren. Pg_crypto stellt prinzipiell nur cryptografische Funktionen zur Verfügung. Löst aber nicht das Problem, dass jeglicher Funktionsaufruf mit Geheimnis über ODBC oder wie auch immer grundsätzlich als unsicher angesehen werden muss, da das Geheimnis im Sql Log sichtbar gemacht werden kann.

Unter der Prämisse, dass jeder postgres Server wegen der möglichen trust Authentifizierung als unsicher angesehen werden muss, kann es auch keine in Funktionen “eingebaute” Geheimnisse geben, da jeder sie nutzen oder einsehen kann. Somit bleibt nur die Anwendung, die dem Server auf Verbindungsebene das Geheimnis mitteilt. Und das auf sicherem Weg. Daher der Diffie, und daher der Aufwand. Ist das Geheimnis erst übertragen, kann die eigentliche cryptografische Funktion generisch genutzt werden, z.B. In Triggern. Ohne weitere Logik in der Anwendung, die sich um nichts mehr kümmern muss.

Das ist unterm Strich u.U. der geringere Aufwand. Vor allem in Verbindung mit historisch gewachsenen legacy Anwendungen, die nachträglich abgesichert werden müssen.

Gibt es Erkenntnisse zum prinzipiellen Vorhaben bezüglich Speicherverwaltung an sich?