Rechte von Triggern

Hallo!

Ich habe eine Frage bezüglich der Rechte von Triggern. Leider habe ich in der PG-Doku nichts dazu gefunden, aber vermutlich war ich einfach zu blind dazu. :-/

So wie ich das sehe werden Trigger mit den Rechten des momentanen Benutzers ausgeführt, auch wenn sie von einem anderen User definiert/ installiert wurden? Stimmt das so?

An einem Beispiel für eine Bilderdatenbank:
Der Superuser hat eine Tabelle für alle User der Bilderdatenbank und natürlich eine Tabelle für die Bilder an sich angelegt.
Die User erhalten nur über Views Zugriff auf die entsprechenden Daten, auch das Einfügen Löschen etc wird via Views + Rules realisiert. (Rules werden ja mit den Rechten des Besitzers der manipulierten Tabellen ausgeführt, in dem Fall also dem Superuser.)

Nun gibt es in der User-Tabelle ein Feld “Quota” in dem der Gesamtspeicherplatz aller Bilder eines Users gespeichert wird. Natürlich könnte ich das Anpassen der Quotas auch direkt in der entsprechenden INSERT-Rule machen, habe mich aber für Trigger entschieden. (War das eine schlechte Entscheidung?)
Als Superuser habe ich also einen Trigger installiert, der bei jedem INSERT auf die Bilder-Tabelle (auf die nur der Superuser Zugriff hat) die Quota in der Usertabelle (Zugriff auch nur Superuser) angepasst wird.
Damit die Sache funktioniert muss die entsprechende Trigger-Prozedur als
“SECURITY DEFINER” angelegt werden. Ich entnehme deshalb, dass der Trigger folglich mit den Rechten des Users ausgeführt wird, obwohl der Superuser den Trigger auf einer Tabelle installiert hat, auf die auch nur er Zugriff hat. Der Trigger wird ja eigentlich auch durch die entsprechende Rule gefeuert, die das INSERT auf eine View des Users umwandelt.

Ist die Verwendung des “SECURITY DEFINER” also die korrekte Möglichkeit, einen Trigger in solchen Fällen zu verwenden?
Wie exakt funktioniert das bei Trigger mit den Rechten (bzw. wo kann ich das nachlesen)?

Danke für’s Lesen und ich würde mich sehr über eine Antwort freuen!

Viele Grüße,
Tim

Der Trigger selbst ist eigentlich unwichtig. Wichtig ist die Funktion, die dabei ausgeführt wird. Und da hast du Recht: die wird als der aktuelle Benutzer gestartet.

Das “SECURITY DEFINER” ist praktisch das “suid” Bit aus Unix: wenn dies gesetzt ist, wird die Funktion mit den Rechten desjenigen ausgeführt, der die Funktion geschrieben hat.

Ansonsten gibt es keine weiteren Rechte: entweder ausführender User und was der darf, wird durch GRANT/REVOKE festgelegt oder halt der erstellende Benutzer.

Hi und danke für die schnelle Antwort!
Jetzt bin ich etwas schlauer, trotzdem finde ich das irgendwie “seltsam”, dass die Trigger-Fkt durch den (Session-) User ausgeführt wird.

Denn: (Session-) User macht ein INSERT auf eine View.
Eine RULE springt ein und macht das INSERT in die reale Tabelle. Die RULE wird dabei mit den Rechten des Besitzers der realen Tabelle (Superuser) ausgeführt. Durch das INSERT auf der realen Tabelle (durch die RULE) wird ein Trigger gefeuert. Die Trigger-Fkt wird nun im Kontext des (Session-) Users ausgeführt. Ich fände es logischer, wenn die Trigger-Fkt im Kontext des Superusers ausgeführt werden würde - immerhin wurde der Trigger durch eine RULE im Kontext des Superusers gefeuert. Wäre der Trigger für die View installiert gewesen (was ja leider nicht geht) fände ich das ganze irgendwie verständlich, aber so?
Habe ich einen Denkfehler oder welcher Gedankengang fehlt mir, um den Zusammenhang zu verstehen?

Weiter habe ich gleich noch eine Frage bzgl. Funktionen und Rechten:
Kann der Zugriff auf eine Funktion nicht auch ebenso wie der Zugriff auf Views gesteuert werden?
Bsp. was ich meine:
Ich erzeuge ein Schema myschema, darin eine Tabelle myschema.mytable, eine View auf die Tabelle myschema.myview und eine Funktion/ Prozedur myschema.myfunction.
Damit ein User nun die View benutzen darf (SELECT), benötigt es ein
GRANT USAGE ON SCHEMA myschema TO user;
GRANT SELECT ON myschema.myview TO user;
In dem Moment, woe die “USAGE” auf das Schema gewährt wurde, darf der User auch die Funktion ausführen. Warum muss ich hier nicht auch erst ein “GRANT EXECUTE ON FUNCTION…” gewährt werden?
Ich habe dann übrigens versucht mit
REVOKE ALL ON FUNCTION myschema.myfunction FROM myuser
den Zugriff auf die Funktion zu verwehren, aber das hat nicht geklappt - der User kann die Funktion trotzdem ausführen.
Werden Funktionen also (von den Rechten her) prinzipiell anders behandelt als Relationen?

Freue mich sehr über aufklärende Antworten! :slight_smile:

Danke und Gruß,
Tim

Eine RULE ist erst einmal nur eine Regel für das Umschreiben eines Statements.

Andreas

Dein (Rechte-) Problem ist:

Durch die Rule erzeugst du praktisch eine neue View (schau dir die Rechte mir \dp an), diese View hat per Default erst mal mehr Rechte als du vielleicht vergeben möchtest.

Wenn du diese Rechte nun auch wieder mit GRANT/REVOKE einschränkst, fällt dein “Rechte des Erstellers” Verdacht in sich zusammen.

Ok, danke für die Hinweise! :slight_smile:
Könnt ihr mir sagen, wo ich auch mehr über Rechte und Funktionen nachlesen kann? (Vgl. meine weitere Frage.)

Danke & Gruß,
Tim

Rechte gehören zum SQL Standard.

PostgreSQL: Documentation: Manuals: PostgreSQL 8.2: GRANT
PostgreSQL: Documentation: Manuals: PostgreSQL 8.2: REVOKE

Ok, danke!
Das Problem hat sich nun gelöst.
Ich habe nicht gewusst, dass PUBLIC automatisch EXECUTE-Recht auf Funktionen bekommt. Ein
REVOKE EXECUTE ON FUNCTION … FROM PUBLIC hat zum gewünschten Erfolg geführt.

Danke nochmals & Gruß,
Tim