定義者のロール権限を使用して、PL/SQLプロシージャで動的DDLを実行します

PL / SQLストアドプロシージャ/関数内でロールを設定できるのは、呼び出し元の権限がある場合のみです。 （AUTHID CURRENT_USER ）（ドキュメントを参照） 。つまり、ops_userを使用してadmin_userのプロシージャを呼び出してから、admin_userのロールにアクセスすることはできません。 DBAがロールを使用してCREATE TABLEを制御することを主張する場合 特権、これが私が以前に見たアプローチです：

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;

これにより、コードを実行するためだけに、一時的にops_userにロールが付与されます。デフォルトでは、ops_userはadmin_userのパッケージ本体ソースを表示できないはずです。パスワードをさらに保護するために、パッケージ本体をラップすることもできます。ただし、パスワードのセキュリティはさておき、このアプローチに関する私の最大の懸念は、Oracleが単一のロールを無効にする優れた方法を提供していないことです。したがって、ops_userにパスワードで保護された他のロールがある場合、このコードは復元しようとするとORA-01979を発生させる可能性があります。それら。

したがって、答えはありますが、他のコメント投稿者が提案したことを実行し、管理者ユーザーにCREATETABLEを付与することをお勧めします。