U kunt alleen een rol instellen binnen een in PL/SQL opgeslagen procedure/functie als deze Invoker's Rights heeft (AUTHID CURRENT_USER
)(zie document)
. Wat betekent dat je ops_user niet kunt gebruiken om de procedure van admin_user aan te roepen en vervolgens toegang te krijgen tot de rollen van admin_user. Als uw DBA's erop staan een rol te gebruiken om de CREATE TABLE
te beheren privilege, dit is de benadering die ik eerder heb gezien:
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;
Dit zal tijdelijk de rol toekennen aan ops_user om uw code uit te voeren. Standaard zou de ops_user niet in staat moeten zijn om de body source van het admin_user pakket te bekijken. U kunt waarschijnlijk de inhoud van het pakket inpakken om het wachtwoord verder te beschermen. Maar afgezien van wachtwoordbeveiliging, is mijn grootste zorg met deze aanpak dat Oracle geen leuke manier biedt om een enkele rol uit te schakelen, dus als ops_user andere met een wachtwoord beveiligde rollen heeft, kan deze code een ORA-01979 oproepen wanneer deze probeert te herstellen hen.
Er is dus een antwoord, maar ik raad je toch aan te doen wat de andere reageerders hebben voorgesteld en CREATE TABLE toe te kennen aan je beheerder.