[Technik] Functions, Triggers und (Procedural) Languages in PostgreSQL, Was: Re: postgresql-contrib-8.1

[Michael Hierweck]

Hallo allerseits,

PostgreSQL ermöglicht die Defintion von Stored Procedures, welche auf
internen Funktionen, SQL und externen Modulen basieren können.
(Letzteres wird von TSearch2 verwendet.) Ferner können sogar neue
Sprachen zur Definition von Stored Procedures hinzugefügt werden. Zu
diesem Zweck wird einen (üblicherweise externe) Stored Procedure, ein
sog. language handler definiert.

(Die folgenden Ausführungen betreffen nicht Stored Procedures, welche in
SQL bzw. mit Hilfe von internen Funktionen definiert sind, um bspw.
updatable views zu ermöglichen.)

"C" steht für ein externes Shared Object.

Dies definiert beispielsweise eine externe Funktion:
CREATE FUNCTION <FUNC_NAME> AS <EXT_MODULE> LANGUAGE C

Dies definiert beispielsweise eine weitere externe Funktion:
CREATE FUNCTION mylang_handler AS $libdir/mylang.so LANGUAGE C

welche nun zur Definition eine neuen Sprache verwendet werden kann:
CREATE LANGUAGE mylang HANDLER mylang_handler

Anschließend können wir neue Funktionen in dieser Sprache definieren:
CREATE FUNCTION myfunc [...] LANGUAGE mylang


Grundsätzlich handelt es sich dabei um ein sehr mächtiges Konzept. Der
Haken: "niemand" weiß, was ein beliebiges externes C-Modul tut. Ein
externes C-Modul hat freien Zugriff und wird mit den Rechten von
postgres als Teil des PostgreSQL-Prozesses ausgeführt.

Das heißt: zunächst dürfen nur Superuser externe C-Module einbinden und
nur Superuser dürfen Functions oder Trigger definieren, welche über
Sprache definiert werden, deren Interpreter auf einem externen C-Modul
basiert.

Nun gibt es Sprachmodule für PostgreSQL, die ähnlich dem PHP Safe Mode
einigen Restriktionen unterliegen, sog. trusted languages.

Selbst wenn der Superuser wie im obigen Beispiel eine neue Sprache
"mylang" definiert hat, können User keine eigenen Funktionen in dieser
Sprache definieren. Wenn der Superuser aber weiß, dass "mylang" sicher
ist, könnte er die Sprache auch als trusted definieren:

CREATE FUNCTION mylang_handler AS $libdir/mylang.so LANGUAGE C
CREATE TRUSTED LANGUAGE mylang HANDLER mylang_handler

Anschließend können auch User eigene Funktionen auf Basis mylang definieren.


Wir haben folgende Möglichkeiten:

a) Wir lassen keine externen Sprachen zu und beschränken damit Stored
Procedures auf SQL und das interne PL/PGSQL. (Damit wäre auch der
Einsatz von tsearch2 nicht möglich.)

b) Wir lassen keine externen Sprachen zu und beschränken damit Stored
Procedures auf SQL und das interne PL/PGSQL. Zusätzlich stellen wir
ausgewählte, als sicher bekannte Funktionen zur allgemeinen Verwendung
zur Verfügung.

c) Wir lassen keine externen Sprachen zu und beschränken damit Stored
Procedures auf SQL und das interne PL/PGSQL. Zusätzlich stellen wir
ausgewählte, als sicher bekannte Funktionen zur allgemeinen Verwendung
zur Verfügung. Darüberhinaus definieren wir diverse sichere Sprachen als
trusted languages, damit User eigene Funktionen darin definieren können.


Kurz: Mehr Freiheit/Leistungsfähigkeit, führt zu potentiell weniger
Sicherheit. Es gibt aber weitere Punkte zu bedenken:
abrechnungstechnisch sind sehr leistungsfähige Stored Procedures
problematisch und im PHP wollen wir schnellstmöglich vom Safe Mode weg.
Es wäre zumindest in hohem Maße fragwürdig.

Persönlich tendiere ich zu b), wenn man "ausgewählt" sehr eng fasst.


Viele Grüße

Michael


P.S. Wie sieht das eigentlich im MySQL-Bereich aus?

-- 
EDV-Serviceteam Werthmann & Hierweck GbR
Annika Werthmann, Michael Hierweck
Egerstraße 53, 44225 Dortmund
http://www.edv-serviceteam.net