Separar sucesso interativo de compilação
O proprietário do código recebe SELECT sobre PAYMENTS apenas através de uma role. Consegue consultar a soma 300 e executar um bloco anónimo que faz a mesma leitura. Porém, criar a view falha e a função armazenada com SQL estático fica INVALID. A role ativa na sessão não substitui os privilégios diretos necessários à compilação deste exemplo. No Oracle Free 26ai ensaiado, CREATE VIEW devolveu ORA-41904, uma mensagem específica de privilégio de objeto em falta; não generalizes um código antigo a todas as versões. USER_ERRORS ajuda a explicar a falha da função. Depois de conceder SELECT diretamente ao proprietário do código e recompilar, a função fica VALID e a view pode ser criada. A ação corretiva é delimitada, em vez de atribuir uma role administrativa para esconder o problema.
Compreender a interface com direitos do proprietário
A função TOTAL_DR usa AUTHID DEFINER e uma referência qualificada à tabela do proprietário dos dados. O proprietário do código possui SELECT direto e concede EXECUTE ao invocador. Esse invocador obtém 300 ao chamar a função, mas uma tentativa de consultar diretamente a tabela continua a falhar. A interface pode expor uma operação delimitada sem conceder leitura arbitrária de todos os dados. Isto exige cuidado no desenho: validação de parâmetros, comportamento autorizado e superfície de operações expostas. O exemplo não recebe SQL livre e não demonstra segurança de uma função que concatene comandos de origem externa. A documentação descreve a alteração do contexto quando uma unidade com direitos do proprietário entra na pilha de chamadas. Roles concedidas ao próprio código são um mecanismo adicional que este exercício não configura.
Avaliar direitos do invocador e herança
TOTAL_IR executa a mesma consulta com AUTHID CURRENT_USER. Nesta chamada direta e com os nomes qualificados do laboratório, o invocador precisa de um caminho de leitura aplicável em execução. EXECUTE sozinho não basta: sem SELECT, a chamada falha; com a role de leitura ativa, devolve 300; com SET ROLE NONE, volta a falhar. Há ainda uma verificação independente de INHERIT PRIVILEGES. O ensaio remove a concessão por omissão a PUBLIC apenas para a identidade sintética e concede a herança estritamente ao proprietário desta função. Retirar essa concessão produz ORA-06598 mesmo quando o invocador tem leitura. Restaurá-la resolve esse erro específico. Não transformes este exemplo numa recomendação de conceder INHERIT ANY PRIVILEGES; a relação necessária pode ser restrita à identidade autorizada.
Testar a revogação na operação dependente
Quando SELECT direto é retirado ao proprietário do código, a leitura interativa ainda funciona pela role, mas as duas funções armazenadas ficam INVALID. No ensaio, a view ainda surge como VALID na primeira consulta de metadata. A consulta seguinte à view falha com ORA-04063. Esta sequência mostra por que motivo uma linha de metadata não deve ser tratada como prova suficiente de acesso após uma mudança. O relatório conserva a ordem dos passos e os erros reais. Restaurar o grant direto e recompilar devolve a operação ao comportamento esperado. Para uma mudança real, identifica dependências antes da revogação, testa os caminhos necessários e proibidos, prepara recuperação e acompanha as ligações da aplicação. O exercício não demonstra todas as combinações de caches, versões, código dinâmico ou grants a unidades PL/SQL.
Preparar um handover que possa ser reproduzido
Entrega à APS um registo com versão do motor, PDB, identidades, objeto, AUTHID, tipo de SQL, grants diretos, roles ativas, operação que passa e operação que falha. Distingue erros de resolução, compilação, execução e herança em vez de os resumir como «permissões». Inclui os comandos de diagnóstico autorizados e o resultado esperado, evitando expor palavras-passe em logs. Neste laboratório, duas execuções independentes passaram 38 verificações cada e removeram os seus utilizadores e role. O contentor e a rede descartáveis também foram removidos. A evidência prova esses comportamentos nos dados sintéticos, não a prontidão de uma aplicação bancária. O aprofundamento foi organizado junto do contexto multitenant e da passagem de código à produção; não cria um novo domínio oficial ou uma ponderação de segurança para o exame.
SELECT SYS_CONTEXT('USERENV','SESSION_USER'),
SYS_CONTEXT('USERENV','CURRENT_USER'),
SYS_CONTEXT('USERENV','CURRENT_SCHEMA'),
SYS_CONTEXT('USERENV','CON_NAME') FROM dual;
SELECT role FROM session_roles;
-- Run only the supplied exercise in its labelled disposable container.TOTAL_DR devolveu 300 sem SELECT do invocador. TOTAL_IR precisou de leitura ativa e herança autorizada. A view falhou apesar do estado VALID observado imediatamente antes.
Armadilhas comuns
EXECUTE como SELECT direto; AUTHID como correção automática da compilação; ignorar herança; VALID como prova de utilização após revogação.
Tópicos relacionados: Contexto multitenant · Passagem à produção · Diagnóstico de acessos
A autorização de código depende da fase e do contexto; reproduzir a chamada relevante é parte da prova de uma mudança de privilégios.
Referência: Invoker's Rights and Definer's Rights (AUTHID Property) · 1Z0-183 public objectives inspected 2026-09-30; revision date not published