Wykonywanie dynamicznego DDL w procedurze PL/SQL poprzez uprawnienia roli definiującego

Możesz ustawić rolę tylko w procedurze/funkcji składowanej PL/SQL, jeśli ma ona Prawa wywołującego (AUTHID CURRENT_USER )(patrz dokument) . Co oznacza, że ​​nie możesz użyć ops_user do wywołania procedury admin_user, a następnie uzyskać dostęp do ról admin_user. Jeśli administratorzy baz danych nalegają na używanie roli do kontrolowania CREATE TABLE przywilej, oto podejście, które widziałem wcześniej:

create or replace package admin_user.role_test authid current_user is
    procedure test_permissions;
end role_test;
/
create or replace package body admin_user.role_test is
    procedure test_permissions is
        v_query_string VARCHAR2(400 CHAR) := 'begin 
dbms_output.put_line(''after'');
for r in (select role from session_roles) loop 
    dbms_output.put_line(r.role); 
end loop;
end;';
    begin
        dbms_output.put_line('before');
        for r in (select role from session_roles) loop
            dbms_output.put_line(r.role);
        end loop;
        DBMS_SESSION.SET_ROLE('CREATE_TABLE_ROLE IDENTIFIED BY "SECRET_PASSWORD"');
        execute immediate v_query_string;
        DBMS_SESSION.SET_ROLE('ALL EXCEPT CREATE_TABLE_ROLE'); -- restore defaults
    end;
end role_test;
/
grant execute on admin_user.role_test to ops_user;

To tymczasowo przydzieli rolę użytkownikowi ops_user tylko po to, aby wykonać twój kod. Domyślnie użytkownik ops_user nie powinien mieć możliwości wyświetlenia źródła treści pakietu administratora_użytkownika. Prawdopodobnie możesz zawinąć treść pakietu, aby dodatkowo chronić hasło. Ale pomijając bezpieczeństwo haseł, moim największym problemem związanym z tym podejściem jest to, że Oracle nie zapewnia dobrego sposobu na wyłączenie pojedynczej roli, więc jeśli ops_user ma inne role chronione hasłem, ten kod może zgłosić ORA-01979 podczas próby przywrócenia ich.

Jest więc odpowiedź, ale nadal polecam robić to, co sugerowali inni komentatorzy, i przyznać CREATE TABLE administratorowi.