Solo puede establecer un rol dentro de un procedimiento/función almacenados PL/SQL si tiene Derechos de invocador (AUTHID CURRENT_USER )(ver documento)
. Lo que significa que no puede usar ops_user para llamar al procedimiento de admin_user y luego acceder a los roles de admin_user. Si sus DBA insisten en usar un rol para controlar CREATE TABLE privilegio, este es el enfoque que he visto antes:
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;
Esto otorgará temporalmente el rol a ops_user solo para ejecutar su código. De forma predeterminada, ops_user no debería poder ver el origen del cuerpo del paquete de admin_user. Probablemente podría envolver el cuerpo del paquete para proteger aún más la contraseña. Pero aparte de la seguridad de la contraseña, mi mayor preocupación con este enfoque es que Oracle no proporciona una buena manera de desactivar una sola función, por lo que si ops_user tiene otras funciones protegidas con contraseña, este código podría generar un ORA-01979 cuando intente restaurar ellos.
Entonces, hay una respuesta, pero aun así recomendaría hacer lo que sugirieron los otros comentaristas y otorgar CREATE TABLE a su usuario administrador.
