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 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;
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.