Du kan bara ställa in en roll inom en PL/SQL-lagrad procedur/funktion om den har Invoker's Rights (AUTHID CURRENT_USER
)(se dokument)
. Vilket innebär att du inte kan använda ops_user för att anropa admin_users procedur och sedan komma åt admin_users roller. Om dina DBA:er insisterar på att använda en roll för att styra CREATE TABLE
privilegium, här är tillvägagångssättet jag har sett tidigare:
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;
Detta kommer tillfälligt att ge rollen till ops_user bara för att exekvera din kod. Som standard ska ops_user inte kunna se admin_users paketkroppskälla. Du kan antagligen slå in paketets kropp för att ytterligare skydda lösenordet. Men bortsett från lösenordssäkerhet är mitt största problem med detta tillvägagångssätt att Oracle inte erbjuder ett bra sätt att inaktivera en enskild roll, så om ops_user har andra lösenordsskyddade roller kan den här koden höja en ORA-01979 när den försöker återställa dem.
Så det finns ett svar, men jag rekommenderar ändå att du gör som de andra kommentatorerna föreslog och beviljar CREATE TABLE till din administratörsanvändare.