sexta-feira, 24 de fevereiro de 2012

Duas Dicas Sobre Privilégios

Primeira dica: Uma procedure/function/package roda sempre* com os privilégios do owner, não do executor. Isso significa que, se o usuário SCOTT precisa rodar uma package do usuário FINANC que acessa 300 tabelas de FINANC, apenas o grant de EXECUTE na package para SCOTT é suficiente. Dentro da execução, valem os privilégios de FINANC.
_
Segunda dica: Dentro de uma procedure/function/package, grants recebidos através de uma role não valem. Se através da role ABC você consegue abrir um SQL*Plus e fazer select na tabela X, isso não lhe dá o direito de fazer o mesmo select dentro de uma procedure sua. Para uso dentro de procedures, o grant tem que ser direto e não via role.
_
Tenha sempre isso em mente quando estiver investigando problemas ligados a grants de privilégios. Você poupará muito esforço inútil.
_
* Exceto quando explicitamente definido pelo pragma AUTHID_CURRENT_USER

3 comentários:

  1. Olá, Rangel.

    Eu sei que este post não é tão recente, mas aproveitando o assunto GRANT:
    Existe alguma forma de revogar o privilégio de SELECT FOR UPDATE de usuário a uma tabela sem precisar dar REVOKE no SELECT?
    Achamos recentemente um desenvolvedor travando processos em produção e gerando ORA-00054. Descobrimos que o comando dele tinha sido um SELECT FOR UPDATE. O mesmo pôde executá-lo mesmo sem privilégio de UPDATE.
    Procurei alguma referêncioa na internet e descobri essa página:
    http://www.dbforums.com/oracle/970495-lock-select-update-statement.html

    Grato pela atenção.

    ResponderExcluir
    Respostas
    1. Cara, eu nunca consegui resolver esse problema. As soluções que encontrei envolviam a criação de views, com union all aqui e ali, tudo tosco. Até o Tom Kyte já mandou SR pra Oracle apontando isso como bug, mas por alguma razão nada foi feito.

      Excluir
    2. Tipo isso: http://blog.tanelpoder.com/2007/11/19/oracle-security-part-2-your-read-only-accounts-arent-that-read-only/

      Excluir