Als PDF Downloaden!

Tipps & Tricks: Das PL/SQL-Berechtigungskonzept in 12c
Bereich:
PL/SQL
Erstellung:
01/2015 HA
Versionsinfo:
12.1
Letzte Überarbeitung:
01/2015 HA
Das PL/SQL-Berechtigungskonzept in 12c
Oracle hat das Berechtigungskonzept zu PL/SQL in Hinblick auf zwei gegensätzliche Szenarien in 12c
ausgebaut:
Szenario 1: Der Ausführende hat mehr Rechte als der Programmierer.
Die Änderung zu diesem Szenario (Privileg "INHERIT [ANY] PRIVILEGES") betrifft ausschließlich
Prozeduren, die mit Invoker Rights arbeiten.
Szenario 2: Der Ausführende hat weniger Rechte als der Programmierer.
Die Änderung zu diesem Szenario (Vergabe von Rollen) betrifft Prozeduren, die mit Invoker Rights
arbeiten oder mit dynamischem SQL.
Beiden Neuerungen gemeinsam ist, dass es um die Überprüfung von Rechten zur Laufzeit geht. Auch weiterhin
benötigt ein Entwickler alle entsprechenden Berechtigungen selber, um eine Prozedur erfolgreich kompilieren zu
können. Dynamisches SQL allerdings wird zur Kompilierzeit nicht ausgewertet.
Hinweis: Hier und im weiteren ist "Prozedur" als Sammelbegriff zu verstehen, der auch Funktionen und Packages
mit einschließt.
INHERIT [ANY] PRIVILEGES
Hier kommt Szenario 1 ins Spiel:
Angenommen, der User ADMIN hat weitreichende Rechte.
Weiter angenommen, der Programmierer SCOTT hat vergleichsweise wenig Rechte.
Nun schreibt SCOTT eine Prozedur mit Invoker Rights (bei Definer Rights spielt das neue Privileg keine Rolle),
die er ADMIN zur Verfügung stellt. Solange es sich um statisches SQL handelt, kann nicht viel passieren, da ja
SCOTT's Berechtigungen zur Compile-Zeit überprüft werden.
Nun könnte aber SCOTT bösartigerweise Befehle in dynamisches SQL verpacken, die weit über seine eigenen
Berechtigungen hinausgehen (z. B. an sich selbst Admin-Rechte vergeben), nicht jedoch über diejenigen von
ADMIN. SCOTT kann so eine Prozedur problemlos erstellen - aber nicht ausführen. ADMIN dagegen kann sie
ausführen.
Um einen solchen Missbrauch ggf. unterbinden zu können, wurde mit Version 12c die Berechtigung INHERIT
[ANY] PRIVILEGES eingeführt. Das Konzept dabei sieht folgendermaßen aus:
Der Eigentümer der Prozedur (in obigem Szenario SCOTT) braucht, sofern er nicht über das Systemprivileg
INHERIT ANY PRIVILEGES verfügt, von dem Benutzer, der die Prozedur später ausführen soll - also hier
ADMIN - , das Objektprivileg INHERIT PRIVILEGES. Hat er das nicht, so kann ADMIN später die Prozedur nicht
ausführen.
Damit sich das Verhalten zwischen 11g und 12c nicht ändert, erhält PUBLIC automatisch für jeden neu
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 1 von 3
Damit sich das Verhalten zwischen 11g und 12c nicht ändert, erhält PUBLIC automatisch für jeden neu
angelegten User dieses Recht. Das können Sie leicht nachprüfen über dba_tab_privs:
SELECT *
FROM dba_tab_privs
WHERE grantee = 'PUBLIC'
AND privilege = 'INHERIT PRIVILEGES';
Oracle empfiehlt jedoch PUBLIC diese Rechte zu entziehen.
Für das oben beschriebene Szenario bedeutet dies:
Hat PUBLIC das Recht INHERIT PRIVILEGES ON USER ADMIN, wie das dem Default entspricht, so wird ADMIN
die Prozedur von SCOTT ausführen können, wie auch schon in 11g. Entzieht ADMIN dieses Recht mit
REVOKE INHERIT PRIVILEGES ON USER ADMIN FROM PUBLIC;
und vergibt das Recht auch nicht explizit an SCOTT, dann kann er keine Prozedur von SCOTT mehr ausführen,
die mit INVOKER RIGHTS angelegt wurde. Beim Versuch erhält er die Fehlermeldung
ORA-06598: Nicht ausreichende INHERIT PRIVILEGES-Berechtigung
Rollen an PL/SQL-Objekte vergeben
Szenario 2 sieht so aus:
User SCOTT stellt wiederum Invoker Rights-Prozeduren zur Verfügung, in diesem Fall für den User LEHRLING.
Eine der Prozeduren greift auf ein Tabelle im Schema SCOTT zu. SCOTT will aber nicht, dass LEHRLING
direkten Zugriff auf diese Tabelle bekommt. Den bräuchte LEHRLING aber bis einschließlich Version 11g, um
diese Prozedur ausführen zu können.
SCOTT erstellt z. B. folgende Funktion:
CREATE OR REPLACE FUNCTION deptno_exists (p_deptno IN SCOTT.DEPT.deptno%TYPE)
RETURN BOOLEAN
AUTHID CURRENT_USER
IS
v_count NUMBER;
v_ret
BOOLEAN;
BEGIN
SELECT COUNT (*)
INTO v_count
FROM scott.dept
WHERE deptno = p_deptno;
IF v_count > 0
THEN
v_ret := TRUE;
ELSE
v_ret := FALSE;
END IF;
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 2 von 3
RETURN v_ret;
END deptno_exists;
/
GRANT EXECUTE ON deptno_exists TO LEHRLING
/
LEHRLING wird diese Funktion bis jetzt nicht erfolgreich ausführen können:
ORA-00942: Tabelle oder View nicht vorhanden
ORA-06512: in "SCOTT.DEPTNO_EXISTS", Zeile 8
In Version 12c stellt nun ein DB-Administrator SCOTT eine Rolle zur Verfügung:
CREATE ROLE select_dept;
GRANT select_dept TO SCOTT WITH ADMIN OPTION;
SCOTT vergibt das benötigte Select-Recht and die Rolle:
GRANT SELECT ON dept TO select_dept;
Und die Rolle an die Funktion(!):
GRANT select_dept TO FUNCTION deptno_exists;
Nun kann LEHRLING die Funktion erfolgreich ausführen ohne direkten Zugriff auf SCOTT.dept zu erhalten.
An dem Grundprinzip, dass Rollen in PL/SQL unwirksam sind, ändert sich nichts: Eine Prozedur kann auch
weiterhin nur dann erfolgreich kompiliert werden, wenn ihr Eigentümer alle dafür erforderlichen Rechte DIREKT
gegrantet bekommen hat.
Ein Beispiel zur Anwendung dieses Rollenkonzepts bei Definer Rights und dynamischem SQL hat Tom Kyte in
seinem Blog beschrieben.
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 3 von 3