Frage zur Rechtevergabe in der Datenbank

[Frickler]

Ich habe einen User in der Datenbank, dessen Zugriff stark eingeschränkt ist. Er darf einen View anschauen und eine SP ausführen. Dementsprechend hat er nirgendwo Rechte in der Datenbank, bis auf ein Leserecht auf den View und ein Ausführungsrecht auf die SP. Beim View gibt es keine Probleme, wohl aber bei der SP.

Diese SP updatet einen Wert in einer Tabelle. Dafür habe ich der SP die Lese- und Update-Rechte für diese Tabelle gegeben.

An der Tabelle hängt ein AfterUpdate Trigger, der in eine Logdatei schreibt. Dafür ruft der Trigger eine SP ("LogSP") auf. Ich habe dem Trigger dafür das Ausführungsrecht für die LogSP gegeben.

Jetzt das Problem: versuche ich mit dem User die SP aufzurufen, meckert Firebird, dass der User kein Recht hat, die LogSP auszuführen. Aber warum?

Gebe ich dem User die Ausführungsrechte für die LogSP, dann gehts. Aber die soll er gar nicht direkt aufrufen dürfen.

[Ghostwalker]

Weil nicht der Trigger das Recht benötigt, sondern der User.

Letztlich wird der Trigger ja durch den User ausgeführt (wenn auch indirekt). Das DBMS prüft aber immer gegen die Berechtigungen des Users.
Dabei spielt die Art und Weise des Aufrufs keine Rolle.

Das er die SP nicht direkt aufrufen dürfen soll, ist eigentliche Sache des Programms, nicht des DBMS. Wenn ich dem User im Programm gar nicht erst die Möglichkeit gebe, direkt eine SP aus zu führen, ist das Problem gelöst

[Frickler]

Zitat von Ghostwalker:

Weil nicht der Trigger das Recht benötigt, sondern der User.

Letztlich wird der Trigger ja durch den User ausgeführt (wenn auch indirekt). Das DBMS prüft aber immer gegen die Berechtigungen des Users.
Dabei spielt die Art und Weise des Aufrufs keine Rolle.

Das er die SP nicht direkt aufrufen dürfen soll, ist eigentliche Sache des Programms, nicht des DBMS. Wenn ich dem User im Programm gar nicht erst die Möglichkeit gebe, direkt eine SP aus zu führen, ist das Problem gelöst

Der "User" ist niemand, der sich am Programm anmeldet oder so. Das Programm hat eine eigene Nutzerverwaltung, die mit den Datenbankusern nichts zu tun hat.
Der "User" ist ein Programm, welches von "außen" auf die Datenbank zugreift. Deswegen hat der auch so wenig Rechte wie möglich.

[jobo]

Nur zum Vergleich, weiß nicht wie es bei Firebird ist:
In Oracle wird zwischen Owner und Invoker unterschieden. Ist eine SP Owner orientiert definiert, so reicht es dem Invoker das Recht auf die SP allein zu geben. Die SP arbeitet dann intern mit Owner Privileges.
Ist die SP als Invoker SP angelegt, so muss ein Verfahren ähnlich wie von Frickler beschrieben verwendet werden, um alle verwendeten Objekte an den Invoker zu berechtigen, damit er letztlich die SP ausführen darf.

Owner privileged SP bzw. Objekte sind der Standard. Demnach werden idR immer nur direkte Rechte auf die benötigten SP weitergegeben.

Dieser Standard scheint mir auch sinnvoll, weil er ziemlich lebensnah am Bedarf ausgerichtet ist.

Das Invoker Verfahren scheint mir eher was für Hochsicherheits-SP.

[IBExpert]

klingt irgendwie alles unvollständig, kannst du eine mini db machen, die den gleichen fehler hat
und dann entweder hier oder mir direkt die metadaten senden?

[Ghostwalker]

Zitat von Frickler:

Zitat von Ghostwalker:

Weil nicht der Trigger das Recht benötigt, sondern der User.

Letztlich wird der Trigger ja durch den User ausgeführt (wenn auch indirekt). Das DBMS prüft aber immer gegen die Berechtigungen des Users.
Dabei spielt die Art und Weise des Aufrufs keine Rolle.

Das er die SP nicht direkt aufrufen dürfen soll, ist eigentliche Sache des Programms, nicht des DBMS. Wenn ich dem User im Programm gar nicht erst die Möglichkeit gebe, direkt eine SP aus zu führen, ist das Problem gelöst

Der "User" ist niemand, der sich am Programm anmeldet oder so. Das Programm hat eine eigene Nutzerverwaltung, die mit den Datenbankusern nichts zu tun hat.
Der "User" ist ein Programm, welches von "außen" auf die Datenbank zugreift. Deswegen hat der auch so wenig Rechte wie möglich.

Ok, das macht die Sache schwieriger, ändert aber auch nix. Denn auch das Programm wird sich mit einem User am DBMS anmelden, wenn es die Connection aufbaut.
Aus Sicht der DB ist es egal, ob der "User" jetzt ein Mensch, ein Programm oder der Ionenfluss ist

So wie es aussieht, prüft die "LogSP" nicht nur die Berechtigung der Aufrufenden Instanz, sondern auch die Berechtigungen des Users.

[Frickler]

Zitat von jobo:

Nur zum Vergleich, weiß nicht wie es bei Firebird ist:
In Oracle wird zwischen Owner und Invoker unterschieden. Ist eine SP Owner orientiert definiert, so reicht es dem Invoker das Recht auf die SP allein zu geben. Die SP arbeitet dann intern mit Owner Privileges.
Ist die SP als Invoker SP angelegt, so muss ein Verfahren ähnlich wie von Frickler beschrieben verwendet werden, um alle verwendeten Objekte an den Invoker zu berechtigen, damit er letztlich die SP ausführen darf.

Die Geschichte mit den Ownern (heißt da "DEFINER") und Invokern wird es meines Wissens nach mit der nächsten Firebird Version 4 geben.

Zitat von IBExpert:

klingt irgendwie alles unvollständig, kannst du eine mini db machen, die den gleichen fehler hat
und dann entweder hier oder mir direkt die metadaten senden?

Ich probiers.

EDIT: Ich konnte das Verhalten in einer kleinen Demo nicht nachstellen.

Nach längerem Rumgraben fand ich dann heraus, dass beim Ausführen meines Scriptes, welches die ursprüngliche Datenbank erzeugt, manche GRANT-Anweisungen übersprungen wurden. Das hat was mit Kommentaren im Script und einem alten UniDAC Bug zu tun, der wohl inzwischen beseitigt wurde.

Langer Rede kurzer Sinn: es funktioniert, so wies soll!