Na maioria dos casos, quando um job \u00e9 criado, alterado e executado pelo seu pr\u00f3prio dono, n\u00e3o h\u00e1 muitas\u00a0complica\u00e7\u00f5es. No entanto, as coisas podem ficar realmente confusas\u00a0principalmente quando trabalhamos em sistemas que envolvem a camada de seguran\u00e7a do Oracle Database Vault e se o job for criado\u00a0por um usu\u00e1rio diferente do seu propriet\u00e1rio.<\/p>\n
Neste artigo, irei mostrar os usu\u00e1rios envolvidos em um Scheduler Job e o papel de cada um.<\/p>\n
Bom, para come\u00e7ar, existem basicamente\u00a03 usu\u00e1rios<\/strong>\u00a0que participam de um Oracle Scheduler Job. S\u00e3o eles:<\/p>\n Para que serve cada usu\u00e1rio \u00e9 o que iremos ver\u00a0a seguir.<\/p>\n O dono do job \u00e9 o schema informado dentro do par\u00e2metro JOB_NAME ao se criar um Job. Se omitido, o dono ser\u00e1 o mesmo usu\u00e1rio que executou o comando de cria\u00e7\u00e3o. No exemplo abaixo, o owner\u00a0\u00e9 o usu\u00e1rio “SCOTT”.<\/p>\n O dono do job ser\u00e1 tamb\u00e9m o seu\u00a0executor<\/u><\/strong>. Se a tarefa roda\u00a0uma procedure ou PL\/SQL, este usu\u00e1rio precisa, portanto,\u00a0ter a permiss\u00e3o<\/u>\u00a0de executar a procedure ou privil\u00e9gios nos objetos acessados pelo c\u00f3digo PL\/SQL. Caso contr\u00e1rio, receber\u00e1 um erro como “ORA-00942: table or view does not exist<\/em>“.<\/p>\n Em caso de execu\u00e7\u00e3o de um PL\/SQL, as vari\u00e1veis de ambiente\u00a0CURRENT_USER<\/em> (esquema cujos privil\u00e9gios est\u00e3o ativos no momento) e CURRENT_SCHEMA<\/em> (esquema default ativo no momento) ser\u00e3o obviamente o dono do job pois, como j\u00e1 informado, ele \u00e9 o executor.<\/p>\n No entanto, em caso de execu\u00e7\u00e3o de uma Procedure, as vari\u00e1veis \u00a0CURRENT_USER<\/em> e CURRENT_SCHEMA<\/em> apontar\u00e3o para o dono da Procedure, j\u00e1 que\u00a0uma procedure ao ser chamada \u00e9 executada com os privil\u00e9gios e padr\u00f5es de seu propriet\u00e1rio (exceto se ela possuir\u00a0“AUTHID CURRENT_USER” que, neste caso, se comportaria similar a um bloco PL\/SQL informado acima).<\/p>\n E se lockarmos o usu\u00e1rio que \u00e9 propriet\u00e1rio? Neste cen\u00e1rio, nada\u00a0interfere e a tarefa continuar\u00e1 executando na forma agendada sem problemas. No entanto, se o propriet\u00e1rio do job for removido, por pertenc\u00ea-lo o agendamento tamb\u00e9m ser\u00e1 apagado.<\/p>\n O criador\u00a0do job \u00e9 o schema que executou a procedure\u00a0DBMS_SCHEDULER.CREATE_JOB. Caso voc\u00ea crie um job para outro usu\u00e1rio, voc\u00ea ser\u00e1 definido como o\u00a0criador<\/u><\/strong>\u00a0daquele job.<\/p>\n OBS: Lembrando que para criar um job em outro schema \u00e9 necess\u00e1rio ter o privil\u00e9gio “CREATE ANY JOB”.<\/em><\/p>\n O criador do job ser\u00e1 o usu\u00e1rio que se conectar\u00e1 na base antes de\u00a0execut\u00e1-lo, apesar do executor ser o propriet\u00e1rio.\u00a0Portanto, a vari\u00e1vel de ambiente\u00a0SESSION_USER apontar\u00e1 sempre para o criador. No entanto, quem cria n\u00e3o precisa de quaisquer privil\u00e9gios nos objetos envolvidos e executados pelo job.<\/p>\n Durante a execu\u00e7\u00e3o do agendamento, se consultarmos a coluna “USERNAME” da v$session, ela retornar\u00e1 o usu\u00e1rio criador (pois \u00e9 ele quem efetuou o login).<\/p>\n No exemplo do item anterior, se o job SCOTT.JOB1 tiver sido criado pelo usu\u00e1rio INFRAUSR, este seria o output da\u00a0v$session<\/strong>\u00a0durante a execu\u00e7\u00e3o da tarefa:<\/p>\n Apesar do usu\u00e1rio que criou ser o utilizado para logar, se ele\u00a0for\u00a0lockado (ou revogarem\u00a0os seus privil\u00e9gios de CREATE SESSION), o job continuar\u00e1 executando normalmente. Isso porque a forma do login para\u00a0a execu\u00e7\u00e3o de um job \u00e9\u00a0diferente. No entanto, fique atento pois jobs disparam triggers de “BEFORE LOGIN”.<\/p>\n E se deletarmos o usu\u00e1rio que criou o job? Nesta situa\u00e7\u00e3o, o job\u00a0n\u00e3o<\/strong>\u00a0\u00e9 deletado, apenas \u00e9 desativado. Ao\u00a0tentar ativ\u00e1-lo, o status do job na all_scheduler_job_logs ser\u00e1 de\u00a0BROKEN. Ser\u00e1 necess\u00e1rio recri\u00e1-lo para que volte a funcionar.<\/p>\n O que pouca gente sabe, \u00e9 que o Oracle mant\u00e9m em seus registros qual foi o usu\u00e1rio que alterou um job pela \u00faltima vez. Esse papel \u00e9 importante apenas em Banco de Dados que possuem Database Vault configurado e quando o job est\u00e1 protegido por um Realm.<\/p>\n Isto porque a \u00faltima pessoa que alterou uma determinada tarefa\u00a0passa a ser monitorada pelo Oracle Database Vault e apenas usu\u00e1rios que possuem\u00a0libera\u00e7\u00e3o em uma camada especial ser\u00e3o liberados.<\/p>\n Qual o motivo desta prote\u00e7\u00e3o?<\/strong>\u00a0Um usu\u00e1rio com o privil\u00e9gio “CREATE ANY JOB” poderia facilmente comprometer o BD ou conseguir uma\u00a0escala\u00e7\u00e3o de privil\u00e9gios,\u00a0criando\/alterando um job de um outro usu\u00e1rio que \u00e9 DBA fazendo com que aquele processo\u00a0fizesse o que ele bem desejasse.<\/p>\n Exemplo:<\/strong><\/p>\n No Oracle Database Vault, isso n\u00e3o seria poss\u00edvel.<\/p>\n Para obtermos o ultimo usu\u00e1rio que alterou um job, precisamos consultar a coluna “RUN_INVOKER<\/strong>” da tabela\u00a0SYS.SCHEDULER$_JOB<\/strong>:<\/p>\n No exemplo acima, o job foi modificado pela \u00faltima vez pelo usu\u00e1rio do\u00a0Oracle OPERUSR.\u00a0Isso significa que caso o OPERUSR n\u00e3o tenha privil\u00e9gios no DB Vault para execut\u00e1-lo, o job apresentar\u00e1 o erro:<\/p>\n Este erro n\u00e3o tem nada a ver com as permiss\u00f5es nos objetos envolvidos, at\u00e9 porque os privil\u00e9gios nos objetos envolvidos, como j\u00e1 dito, quem precisa ter \u00e9 o dono do job, que no caso \u00e9 o SCOTT.<\/p>\n Ent\u00e3o qual privil\u00e9gio \u00e9 necess\u00e1rio?<\/strong> Apenas o simples privil\u00e9gio de que aquele job estar\u00e1 liberado a executar para\u00a0o usu\u00e1rio que o modificou pela \u00faltima vez.<\/p>\n No Database Vault, logado como DV Owner, esta autoriza\u00e7\u00e3o pode ser concedida\/consultada executando:<\/p>\n Por fim, como pudemos ver neste artigo, um job pode ser mais complexo do que parece. Caso voc\u00ea esteja tendo problemas de privil\u00e9gio em alguma de suas tarefas agendadas, n\u00e3o esque\u00e7a de consultar qual \u00e9 o papel de cada usu\u00e1rio que est\u00e1 participando e se todos t\u00eam os privil\u00e9gios adequados.<\/p>\n <\/p>\nGostou? N\u00e3o deixe de comentar ou deixar um \ud83d\udc4d!<\/b>\n\n
1 \u2013 O Dono do Job<\/strong><\/h3>\n
BEGIN\r\n DBMS_SCHEDULER.CREATE_JOB(JOB_NAME => 'SCOTT.JOB1', ..........);\r\nEND;\r\n\/<\/pre>\n
2 \u2013 O Criador\u00a0do Job<\/strong><\/h3>\n
SQL> select username,schemaname,status,program,type,module,action from v$session where module='DBMS_SCHEDULER';\r\n \r\nUSERNAME SCHEMANAME STATUS PROGRAM TYPE MODULE ACTION\r\n-------------- --------------- -------- ---------------------------- ---------- ------------------- --------\r\nINFRAUSR SCOTT ACTIVE oracle@localhost (J000) USER DBMS_SCHEDULER JOB1\r\n \r\nSQL><\/pre>\n
3 \u2013\u00a0O \u00daltimo “modificador” do Job<\/strong><\/h3>\n
BEGIN\r\n DBMS_SCHEDULER.CREATE_JOB(\r\n JOB_NAME => 'SCOTT.JOB_TEMP',\r\n JOB_TYPE => 'PLSQL_BLOCK',\r\n JOB_ACTION => q'[BEGIN EXECUTE IMMEDIATE 'GRANT SELECT ON SCOTT.EMP TO MYUSER'; END;]',\r\n ENABLED => TRUE);\r\nEND;\r\n\/ \r\n<\/pre>\n
SQL> col job_creator format a25\r\nSQL> col job_owner format a25\r\nSQL> col job_name format a25\r\nSQL> col perms_check_user format a25\r\n \r\nSQL> SELECT JU.NAME \"JOB_OWNER\",\r\n 2 JO.NAME \"JOB_NAME\",\r\n 3 J.CREATOR \"JOB_CREATOR\",\r\n 4 JR.NAME \"JOB_MODIFIER\"\r\n 5 FROM SYS.SCHEDULER$_JOB J,\r\n 6 SYS.USER$ JU,\r\n 7 SYS.USER$ JR,\r\n 8 SYS.OBJ$ JO\r\n 9 WHERE J.RUN_INVOKER = JR.USER# (+)\r\n 10 AND J.OBJ# = JO.OBJ#\r\n 11 AND JO.OWNER# = JU.USER#\r\n 12 AND JO.NAME = 'JOB_TEST';\r\n \r\nJOB_OWNER JOB_NAME JOB_CREATOR JOB_MODIFIER\r\n------------------------- ------------------------- ------------------------- -------------------------\r\nSCOTT JOB_TEST INFRAUSR OPERUSR<\/pre>\n
ORA-12012: error on auto execute of job \"SCOTT\".\"JOB_TEST\"\r\nORA-01031: insufficient privileges\r\nORA-06512: at line 2<\/pre>\n
SQL> EXEC DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER(UNAME => 'OPERUSR', SNAME => 'SCOTT');\r\n \r\nPL\/SQL procedure successfully completed.\r\n \r\nSQL> col grantee format a30\r\nSQL> col schema format a30\r\nSQL> select * from dvsys.dba_dv_job_auth;\r\n \r\nGRANTEE SCHEMA\r\n------------------------------ ------------------------------\r\nOPERUSR SCOTT<\/pre>\n
