2012-11-15 14 views
11

Ho bisogno di usare la procedura dbms_lock.sleep dall'utente usr1. Non riesco ad accedere come sys, ma ho una password per utente usr2 che ha il privilegio di "concedere qualsiasi privilegio dell'oggetto". Tuttavia, quando sono entrato come USR2 e cercare di rilasciareCome concedere esecuzione su dbms_lock in Oracle?

grant execute on sys.dbms_lock to usr1 

ottengo l'eccezione ORA-01031 "privilegi insufficienti". Lo stesso funziona con un pacchetto di test su un altro utente. I pacchetti di sistema sono trattati in modo speciale o ho perso qualcosa?

+0

Oracle ha [promesso di risolvere il problema in una versione futura aggiungendo una procedura 'sleep' a' dbms_session'] (https://community.oracle.com/ideas/4852). –

risposta

11

I pacchetti di sistema vengono trattati in modo specifico, in base al valore del parametro di inizializzazione O7_DICTIONARY_ACCESSIBILITY. Se è FALSE, che è l'impostazione predefinita da Oracle 9i, i privilegi ANY non si applicano al dizionario dati. La documentazione si riferisce a questo come "protezione del dizionario".

Il più vicino che posso trovare nella guida di sicurezza - here e here - solo fare riferimento alle tabelle come esempi.

La nota di supporto Oracle 174753.1, tuttavia, afferma esplicitamente che la protezione del dizionario sostituisce grant any object privilege. Non posso citarlo ma spiega quello che stai vedendo; potrebbe valere la pena cercare se si ha accesso ad esso.

Quindi, l'unico modo per usr2 per essere in grado di grant execute on sys.dbms_lock to usr1 è che DBA abbia eseguito grant execute on sys.dbms_lock to usr2 with grant option.

Come dice Ben, è necessario richiedere al DBA di concedere l'autorizzazione allo usr1 direttamente o aggiungere lo with grant option ai privilegi concessi a usr2; oppure fare in modo che usr2 crei una procedura di wrapper attorno alla chiamata dbms_lock e concedere le autorizzazioni su quello a usr1.

+0

Si è appena imbattuto in [questa vecchia risposta] (http://stackoverflow.com/a/2564566/266304) che mostra un wrapper attorno a 'dbms_lock'. –

4

It suoni come se a SYS non è stato assegnato il ruolo DBA o che SYS non disponga del privilegio GRANT ANY OBJECT. Per citare the documentation

Per concedere un privilegio oggetto, è necessario possedere l'oggetto, o il proprietario del l'oggetto deve aver concesso i privilegi degli oggetti con la sovvenzione OPTION, oppure è necessario è stata concessa la GRANT QUALUNQUE OBJECT PRIVILEGE privilegio di sistema. Se si dispone del GRANT QUALSIASI OGGETTO PRIVILEGIO, è possibile assegnare il privilegio dell'oggetto solo se il proprietario dell'oggetto può disporre dello stesso privilegio oggetto per .

Ciò implica che non è possibile concedere l'esecuzione su dbms_lock perché SYS non sarebbe stato in grado di farlo.

Sull'installazione SYS is automatically granted the DBA role così forse qualcuno sta cambiando questo o ha creato un altro utente con il ruolo DBA.

In entrambi i casi dovrai coinvolgere il tuo DBA se hai solo accesso a questi due utenti. Chiedi loro di concedere l'esecuzione sui pacchetti necessari agli utenti che ne hanno bisogno. Spetta a loro darti una buona ragione per cui non ti concederanno di eseguire i pacchetti necessari per svolgere il tuo lavoro.

Se non è possibile ottenere l'accesso completo a dbms_lock è sempre possibile creare una procedura in un altro utente che include lo dbms_lock.sleep necessario e quindi concedere l'esecuzione solo su tale procedura.

+2

Vedo la stessa cosa (11gR2); ma 'SYS' può senz'altro concedere l'esecuzione su' dbms_lock', e apparentemente lo deve concedere a 'usr2' o ottiene un errore di tabella sconosciuto piuttosto che privilegi insufficienti. La stessa cosa succede con altri pacchetti, non solo quello. Anche se non l'ho ancora trovato documentato da nessuna parte, sembra che gli oggetti 'SYS' abbiano un altro livello di protezione; che immagino non sia del tutto irragionevole. Interessante. –

+1

Controllerò quello che dici, ma penso che un utente possa sempre concedere l'esecuzione sul proprio pacchetto a chiunque, no? –

Problemi correlati