Можете да зададете роля в рамките на PL/SQL съхранена процедура/функция само ако има Права на Invoker (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, когато се опита да възстанови тях.
И така, има отговор, но все пак бих препоръчал да направите това, което другите коментатори предложиха, и да предоставите CREATE TABLE на вашия администраторски потребител.