Menu de navegação

[Claudio ReisParticipant]

E ae pessoal,
Gostaria de saber se tem algum comando que veja os grants dados a um objeto…
Tenho um objeto que se eu faço select ele executa mas se eu tento compilar dentro de uma package ele gera erro de privilegios…

[C-S-RParticipant]

Opa Claudio blz?

Talvez vc tenha que ser um pouco mais especifico com oq vc quer e qual o problema. rsrsrs.

Tem a tabela DBA_TAB_PRIVS, não sei se ajuda.

O usuário que vc faz o select é o mesmo que esta compilando a package? O Owner da package é o mesmo do select?

[Claudio ReisParticipant]

Entao o meu problema é eu compilar esta package, eu compilo a package e gera o erro de previlegios neste sinonimo ou tabela (pois sao 4 objetos que acontecem isso )mas se eu executo o select com o mesmo owner fora da package ele executa o select … na package ele faz somente select.
Este objeto ele estava numa package customizada no oracle R11 e eu estou passando para o R12 no select * from DBA_SYS_PRIVS WHERE GRANTEE LIKE ‘O USUARIO’ eles estão iguais nos 2 ambientes…
o admin_option estão com NO em tudo mas esta assim na R11 ja…

[José Laurindo ChiappaModerator]

Blz ? Então, a parte do “privilegios de um owner” Não faz o Menor Sentido, o OWNER de um objeto naturalmente e Irremediavelmente Já POSSUI TODOS os privilégios nos objetos que pertencem a ele….

Segundo, pelo que vc descreve o seu “problema” aí é desconhecer o fato que por default dentro de um stored PL/SQL (seja Procedure, Function, Package ou Trigger) por default as roles são DESLIGADAS, então quaisquer privilégios que um dado usuário recebeu POR ROLES vão ser *** DESATIVADOS *** dentro de um stored PL/SQL, seja ele qual for…. Isso *** SEMPRE FOI ASSIM ***, se vc olhar em https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1065832643319 vc vai ver uma pergunta de DEZESSETE ANOS ATRÁS exatamente sobre o mesmo tópico… DE MODO ALGUM isso é NOVIDADE, sim sim ???

Essa mesma URL que indiquei lista algum das soluções possíveis, tais como : dar os GRANTs *** diretamente *** para o usuário que vai criar o stored PL/SQL desprezando as ROLEs (minha opção preferida), ** OU ** criar o stored PL/SQL com autenticação INVOKER´S RIGHT, onde os privilégios vão ser conferidos de acordo com o usuário que chama o stored PL/SQL , e não com quem o cria : https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1168835334321 é um exemplo, veja a cláusula AUTHID CURRENT_USER ….

Agora sim a sua resposta mais diretamente : todos os privilégios estão registrados nas tabelas do dicionário de dados, mas além da DBA_TAB_PRIVS acho que vc estava falhando em não consultar a DBA_ROLE_PRIVS…. Eis um script já pronto que costumo usar para esse tipo de consulta :

set echo off
set verify off
set pages 9999
col granted_role form a25
col owner form a15
col table_name form a33
col privilege form a33
ACCEPT username prompt ‘Enter Username : ‘
PROMPT Roles granted to user
SELECT granted_role,admin_option,default_role
FROM dba_role_privs
WHERE grantee=UPPER(‘&username’)
ORDER BY 1;
PROMPT Table Privileges granted to a user through roles
SELECT granted_role, owner, table_name, privilege
FROM ( SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER(‘&username’)
UNION
SELECT granted_role
FROM role_role_privs
WHERE role in (SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER(‘&username’)
)
) roles, dba_tab_privs
WHERE granted_role=grantee
ORder by 1,2,3,4;
PROMPT System Privileges assigned to a user through roles
SELECT granted_role, privilege
FROM ( SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER(‘&username’)
UNION
SELECT granted_role
FROM role_role_privs
WHERE role in (SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER(‘&username’)
)
) roles, dba_sys_privs
WHERE granted_role=grantee
ORDER BY 1,2;
PROMPT Table privileges assigned directly to a user
SELECT owner, table_name, privilege
FROM dba_tab_privs
WHERE grantee=UPPER(‘&username’)
ORDER BY 1,2,3;
PROMPT System privileges assigned directly to a user
SELECT privilege, admin_option
FROM dba_sys_privs
WHERE grantee=UPPER(‘&username’);
undefine username
/

==> Vou rodar esse script contra um dado usuário no meu banco :

SYSTEM:@XE:SQL>@privs_by_user
Enter Username : HR
Roles granted to user

GRANTED_ROLE ADM DEF
————————- — —
HR_PESQUISA_T1 NO YES
RESOURCE NO YES

Table Privileges granted to a user through roles

GRANTED_ROLE OWNER TABLE_NAME PRIVILEGE
————————- ————— ——————————— ———————————
HR_PESQUISA_T1 SYSTEM T1 SELECT

System Privileges assigned to a user through roles

GRANTED_ROLE PRIVILEGE
————————- ———————————
RESOURCE CREATE CLUSTER
RESOURCE CREATE INDEXTYPE
RESOURCE CREATE OPERATOR
RESOURCE CREATE PROCEDURE
RESOURCE CREATE SEQUENCE
RESOURCE CREATE TABLE
RESOURCE CREATE TRIGGER
RESOURCE CREATE TYPE

8 linhas selecionadas.

Table privileges assigned directly to a user

OWNER TABLE_NAME PRIVILEGE
————— ——————————— ———————————
SYS DBMS_STATS EXECUTE
SYSTEM CODIGO_DDL INSERT
SYSTEM CODIGO_DDL SELECT

System privileges assigned directly to a user

PRIVILEGE ADM
——————————— —
CREATE VIEW NO
SELECT ANY DICTIONARY NO
UNLIMITED TABLESPACE NO
CREATE DATABASE LINK NO
CREATE SEQUENCE NO
CREATE SESSION NO
ALTER SESSION NO
CREATE SYNONYM NO

8 linhas selecionadas.

SYSTEM:@XE:SQL>

====>> OK ???? Vamos a um exemplo, onde o usuário HR tem um sinônimo apontando para a tabela T1 no schema SYSTEM (só pra não ter que escrever SYSTEm.T1 no código), recebeu o priv de SELECT via uma role, E portanto pode consultar livremente no SQL (onde as roles estão ativas) mas NÂO no stored PL/SQL com autenticação default (onde ROLEs tão desligadas) :

HR:@xe:SQL>create synonym T1 for system.t1;

Sinônimo criado.

HR:@xe:SQL>select object_id, object_name from T1 where rownum create or replace procedure P1 is
2 x number;
3 BEGIN
4 select count(*) into x from T1;
5 end;
6 /

Advertência: Procedimento criado com erros de compilação.

HR:@xe:SQL>show errors
Erros para PROCEDURE P1:

LINE/COL ERROR
——– —————————————————————–
4/4 PL/SQL: SQL Statement ignored
4/32 PL/SQL: ORA-00942: a tabela ou view não existe
HR:@xe:SQL>

===>> aplicando uma das Soluções, que é autorização FORA das ROLEs :

SYSTEM:@XE:SQL>grant SELECT ON T1 to hr;

Concessão bem-sucedida.

SYSTEM:@XE:SQL>

==> agora sim o stored PL/SQL pode acessar o objeto :

HR:@xe:SQL>create or replace procedure P1 is
2 x number;
3 BEGIN
4 select count(*) into x from T1;
5 end;
6 /

Procedimento criado.

HR:@xe:SQL>

HR:@xe:SQL>desc P1
PROCEDURE P1

HR:@xe:SQL>

==>> Criado e compilado SEM ERRORS. c.q.d.

[]s

Chiappa

[José Laurindo ChiappaModerator]

Detalhe : justamente pelo fato de que o OWNER já tem privilégios naturalmente, é PRAXE num database Oracle ter um schema APP_OWNER que é o dono da Aplicação (nenhum usuário se conecta no banco con esse username em princípio, ele só serve para armazenar/conter as TABELAS e ** TAMBÉM ** as Procedures/Functions/Packages/triggers…. Criando tudo centralizado, além de não ter que se preocupar com ROLEs e Privilégios/autenticação, como o stored PL/SQL roda sob o schema que já é dono de tudo é só o usuário final receber o GRANT de EXECUTE no stored PL/SQL e cabou, tudo simplesmente Roda…

[]s

Chiappa

[Author]

Posts