oracle_92 database trigger grant

[mme]

Hallo,

ich habe einen Trigger angelegt der auf Datenbankebene auf das ereignis grant reagiert.

Weiß jemand wie ich /ob ich herausbekomme was (also welche Rolle oder Recht) gerade an wenn (welcher User oder Rolle) gegranted wurde?

Also sowas wie bei row-Triggern wo man "if inserting", oder ":new.spalte" usw. abfragen kann???

Danke im vorraus....

[mme]

Also habe inzwischen selber auch was gefunden. Hier ein kleines Testbeispiel:

CREATE OR REPLACE TRIGGER "VERWALTUNG"."TEST" BEFORE

GRANT ON DATABASE declare

begin

INSERT INTO test

SELECT ora_sysevent, ora_dict_obj_owner,

ora_dict_obj_name, USER, SYSDATE

FROM dual;

end;

Soweit der Trigger. Lässt sich auch komilieren, und schreibt dann wenn man Rechte auf objekte eines anderen Users granted auch in die Tabelle rein. Allerdings nur wer, welches objekt gegranted hat, aber nicht an wenn?

Ausserdem bleiben die spalte 2 und 3 leer wenn man einen Rolle granted (natürlich, aber welche werte muss ich auslesen um das auch noch zubekommen?)...?

[Amstelchen]

hilfts dir vielleicht, wenn du AFTER GRANT ON DATABASE verwendest?

dann sollten nämlich auch deine grants in den folgenden views zu sehen sein:

user_sys_privs, role_sys_privs und user_role_privs.

s'Amstel

[mme]

Leider nicht wirklich, da ich ja dann um herauszubekommen was passiert ist vorher diese Views abfragen muss und danach, um dann durch einen Vergleich herauszubekommen was geändert wurde.

Dieses vorgehen ist mir irgendwie zu krum....

Ich suche erstmal weiter.

Mein Problem ist halt, das ich bei der Vergabe/Entzug bestimmter Rollen ein paar Überprüfungen und Eintragungen in verschiedenen Tabellen machen möchte...

[Amstelchen]

hmm... was noch gehen würde, ist aber vermutlich auch nicht exakt das gewünschte und wieder fitzelei.

AUDIT SYSTEM GRANT [bY ACCESS oder BY SESSION] WHENEVER [NOT] SUCCESSFUL

dann landen alle grants im dba_audit_trail bzw. der tabelle aud$ (ungetestet).

voraussetzung: deine 9.2er datenbank muss auditing aktiviert haben.

ansonsten, in forums.oracle.com oder news:comp.databases.oracle.* sollte sowas eigentlich schon mal besprochen worden sein.

s'Amstel

[mme]

Audit habe ich zwar gerade nicht an, aber da spricht nichts dagegen... Diese Lösung gefällt mir schon besser, da werde ich mich wohl mal vertiefend beschäftigen...

In Metalink usw. habe ich bis jetzt nichts finden können...

erstmal Danke (und für weitere vorschläge weiterhin offen)...

Grüße mme

[schawenn]

Versuche es mal damit:

**************************************************************************************

CREATE OR REPLACE TRIGGER grant_test

BEFORE GRANT ON DATABASE

DECLARE

user_list ora_name_list_t;

BEGIN

FOR i IN 1 .. ora_grantee(user_list)

LOOP

INSERT INTO user.t_log

VALUES(user_list(i), ora_dict_obj_owner, ora_dict_obj_name, ora_dict_obj_type, SYSDATE);

END LOOP;

END;

**************************************************************************************

Habe den Trigger als "sys" angelegt.

Schreibt folgendes heraus:

user_list(i) --> Grantee

ora_dict_obj_owner --> Besitzer des Objektes

ora_dict_obj_name --> Name des Objektes

ora_dict_obj_type --> Type des Objektes

SYSDATE --> aktuelles Datum

mfg

schawenn

[schawenn]

So bekommst du den wirklichen Objekt-Typ heraus:

************************************************************************************

CREATE OR REPLACE TRIGGER grant_test

BEFORE GRANT ON DATABASE

DECLARE

user_list ora_name_list_t;

BEGIN

FOR i IN 1 .. ora_grantee(user_list)

LOOP

INSERT INTO Krei_owner.t_log

VALUES(user_list(i), ora_dict_obj_owner, ora_dict_obj_name, (SELECT object_type FROM all_objects WHERE owner = ora_dict_obj_owner AND object_name = ora_dict_obj_name), SYSDATE);

END LOOP;

END;

***********************************************************************************

[mme]

erstmal danke, aber ich bekomme auch bei deinem Trigger nicht raus an wenn gegranted wurde und wie das objekt heißt wenn es eine Rolle ist... ?

[schawenn]

Ja sorry, habe das mit der rolle überlesen. Schaue aber mal nach, ob sich das nicht auch lösen lässt.

[schawenn]

Probier mal folgendes:

Ausgangssituation:

- default User --> sys, system, usw.

- 2 User --> Krei_Owner und Krei_User

- Krei_Owner besitzt eine Tabelle "t_log"

--> t_log-Aufbau

GRANTED_TO_USER (VARCHAR2(4000))

OWNER (VARCHAR2(4000))

OBJECT_NAME (VARCHAR2(4000))

OBJECT_TYPE (VARCHAR2(4000))

DATUM (DATE)

Ich habe mit dem User "sys" einen Trigger angelegt, welcher vor dem Grant durchlaufen wird:

*******************************************************************

*  Before Trigger

*******************************************************************

CREATE OR REPLACE TRIGGER grant_test

 BEFORE GRANT ON DATABASE

DECLARE

  user_list ora_name_list_t;

BEGIN

  FOR i IN 1 .. ora_grantee(user_list) 

  LOOP 

    IF ora_dict_obj_type = 'ROLE PRIVILEGE' THEN

      INSERT INTO Krei_owner.t_log

        VALUES(user_list(i), 'ROLE PRIVILEGE', '', 'ROLE', SYSDATE);

    ELSE

      INSERT INTO Krei_owner.t_log

        VALUES(user_list(i), ora_dict_obj_owner, ora_dict_obj_name, (SELECT object_type

                                                                       FROM all_objects

                                                                      WHERE owner = ora_dict_obj_owner

                                                                        AND object_name = ora_dict_obj_name), SYSDATE);

    END IF;                                                                      

  END LOOP;   

END;

Hierbei ist zu beachten, dass der Trigger zuerst abfragt, ob es sich um einen Grant für eine Rolle handelt.

Wenn ja, fügt er in die Tabelle "t_log" nur den "granted_to_user" ein, beim "Object_Owner" trägt er 'ROLE PRIVILEGE' ein, das Feld "Object_Name" lässt er leer, "Objekt_Type" wird 'ROLE' eingetragen und im Feld "DATUM" das aktuelle Datum mit Uhrzeit.

Wenn es kein Grant für eine Rolle ist, trägt er alle Daten in die Felder ein, inklusive Object_Name, da der Trigger diesen Namen dann hat, wenn es ein Objekt ist.

Dann habe ich noch einen AFTER TRIGGER geschrieben (ebenfalls unter dem User "sys"), der nach dem GRANT durchlaufen wird:

*******************************************************************

*  After Trigger

*******************************************************************

CREATE OR REPLACE TRIGGER grant_test2

 AFTER GRANT ON DATABASE

DECLARE

  user_list ora_name_list_t;

BEGIN

  FOR i IN 1 .. ora_grantee(user_list)

  LOOP

    UPDATE Krei_owner.t_log t

       SET t.object_name = (SELECT granted_role

                              FROM dba_role_privs                                   

                             WHERE grantee = user_list(i)

                               AND granted_role NOT IN (SELECT object_name

                                                          FROM Krei_owner.t_log

                                                         WHERE grantee = granted_to_user

                                                           AND object_name IS NOT NULL))

     WHERE granted_to_user = user_list(i)

       AND object_name IS NULL;

  END LOOP;

END;

Hierbei ist zu beachten, dass der Trigger sich die Tabelle "t_log" ansieht gefiltert durch den granted_to_user und wo objekt_name NULL ist. Denn dadurch bekommen wir den Datensatz des zugeordneten Users, aus der Liste, der angelegt wurde bei einem GRANT auf eine Rolle (Denn bei einem Grant auf eine Rolle ist das Feld Objekt_Name nicht ausgefüllt worden).

Er editiert den Datensatz und fügt die Rolle hinzu, welche noch nicht unter dem User in der Tabelle "t_log" vorhanden ist (Vergleich mit "dba_role_privs").

Wenn ein Grant auf ein Objekt durchgeführt wurde, findet er keinen Datensatz mit leerem Feld "Objekt_name" und brauch somit keinen Datensatz zu editieren.

Vorsicht: Es dürfen vorher keine Rechte auf Rollen vergeben worden sein. denn ansonsten fliegt der AFTER TRIGGER auf die Nase.

Eine Absicherung müsste noch eingebaut werden. Hatte aber keine Zeit mehr. Sorry.

Ich hoffe, dass diese Lösung dir ein wenig weiterhilft. Sie ist zwar bestimmt nicht das Optimum, aber fürs erste reicht, denke ich.

mfg

schawenn

[mme]

Hab vielen Dank...

ja, kann man noch ein bischen ausbauen, aber die idee und der Trigger so weit ist gut.

Geht so ein bischen in die Richtung, sich vorher merken was der User hatte und dann mit hinterher vergleichen, nur ein bischen komfortabler...

[schawenn]

Genau. Ne komfortablere Lösung mit vordefinierten Funktionen, Prozeduren oder mit Hilfe des DataDictionary habe ich nicht gefunden.

Für Grants auf Objekte, kein Problem, aber mit Grants auf Rollen, hab ich mich dumm und dämlich gesucht und nichts gefunden. Geben tuts da bestimmt irgendetwas, nur was??

Aber hauptsache, du kommst jetzt etwas weiter.