...
falamos, falamos, e então concluí que a usuaria ADRIANAV grava na auditoria
pois a mesma tem acesso na tabela de Horario (que dispara a trigger).. beleza!
Agora só preciso descobrir pq em algumas circunstancias não gravou!
Muito Obrigada
Cris
----- Original Message -----
From: jlchiappa
To: oracle_br@yahoogrupos.com.br
Sent: Thursday, February 09, 2006 6:50 PM
Subject: Fw: [oracle_br] Re: duvida de privilegios - a duvida continua
Uma outra chance : ao invés da questão de privilégios, de repnte PODE
SER que simplesmente a trigger que faz a auditoria não esteja
disparando! Uma trigger não dispara se :
a) for desabilitada via ALTER
ou
b) nem todas as condições forem preenchidas - por exemplo, a condição
WHEN, se vc tiver uma WHEN SALARIO > 1000 (digamos), ou ainda se a
trigger especifica as colunas e nenhuma delas foi
alterada/mexida/citada no SQL. Um caso derivado é simplesmente se
algum IF do trigger body que autorize o insert na tabela de audit não
for satisfeito
ou
c) quando se faz SQL em direct path, como por exemplo sqlloader com
direct=y
veja lá se algum desses casos nãopode estar acontecendo.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu
>
> >>Chiappa, posso comentar?
>
> mais que pode, DEVE, é pra isso que estamos aqui...
>
> >> -->> Só existem sinonimos públicos no nosso database,
>
> confirme isso consultando a DBA_SYNONYMs, não acredite no "oficial"
>
>
> >> inclusive existe um para
> a F_AUDITORIA
>
> NÂO deveria haver nenhum !!! Esse objeto de auditoria NÂO é algo
> público, que vc queira que qualquer um acesse!!! Ele só deveria ser
> acessado PELA TRIGGER de auditoria, que como mostrado SE pertencente
> ao mesmo schema dono da tabela, ocorre naturalmente o acesso, veja
> que foi EXATAMENTE isso que mostrei no meu exemplo, nem SCOTT nem o
> outro cara tinham acesso à tab de auditoria, nem havia sinônimo de
> qquer tipo ....
>
> o usuário PUBLIC não tem privilégio em nenhuma tabela .. nenhuma!
>
> CONFIRME isso consultando em TODAS as fontes possíveis : eu vi na sua
> resposta que vc consultou DBA_TAB_PRIVS, DBA_TAB_COLUMNS e
> DBA_ROLE_PRIVS, mas não vi consulta nem na role_role_privs nem
> recursiva na DBA_ROLE_PRIVS, e também não vi menção à SYS_PRIVS (pro
> caso de alguém ter recebido SELECT ANY TABLE) , um script mais
> completo seria :
>
> /* PRIVS_BY_USER */
> set echo off
> set verify off
> set pages 200
> col granted_role form a20
> 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');
>
> e vc rodaria este script contra PUBLIC, contra o usuário dono das
> tabs, e contra o usuário final,o tal do user1 aí.
>
> ==> e outra coisa, tenha CERTEZA que a aplicação não faz muda isso
> dinamicamente (via ALTER SESSION, ou SQL dinâmico), e que não há
> triggers de banco (tipo triggers de logon, ou similares) envolvidas.
>
> >> -->> Tudo indica que estava faltando acesso, então é normal o dbms
> tem horas
> que deixa gravar, e horas que não grava?
>
> não, OU vc tem o acesso ou não tem, não existe isso de hora gravar
> ora não
>
> >> Bom ela nao tem acesso na F_AUDITORIA, mas como ela ja gravou isso
> HJ?
>
> é o que eu te mostrei no exemplo, SE há uma trigger pertencente ao
> MESMO dono da tabela, e se é feito GRANT de DML dessa tabela , a
> trigger será executada automaticamente, e como a trigger PERTENCE ao
> mesmo usuário-dono, ela será executada com as permissões desse
> usuário-dono, a tabela de auditoria será normalmente gravada pela
> trigger, pois a trigger tem o acesso nesse caso...
>
> >>> b) dispara na MESMA transação, então se o cliente fizer um
> ROLLBACK
> (seja rollback automático por erro, seja de propósito),o INSERT na
> tabela de AUDIT *** vai *** ser desfeito.... Pra isto, AUTONOMOUS
> TRANSACTION é a solução.
> -->> Ué mas não tem de ser desfeito mesmo? se foi feito o rollback na
> inserção
> da tabela de horario, não tem de "sair" da tabela de auditoria?
> entendi
> errado????
>
> é que eu estava pensando na seguinte hipótese : imagine que o usuário
> fez uma operação que deu erro, ou então saiu da aplicação sem gravar,
> e (erradamente!) a aplicação não mostra nada pra ele : nesse caso a
> transação vai ser desfeita, e o insert na tabela de auditoria vai
> sumir também, aí lá vem o usuário reclamando que não houve
> auditoria.... Pra vc comprovar que é isso, vc pode (por exemplo) ter
> uma trigger que registra os erros da base (evento on servererror),
> e/ou ainda ter uma transação autônoma na trigger de auditoria, OU
> ainda melhor, acionar o comando AUDIT nesse banco, que aí não tem
> como, afora acessos de DBAs audit NECESSARIAMENTE captura o que vc
> especificar.
>
> afaik é checar essas possibilidades, só assim vc vai descobrir o que
> está diferente nesse banco.
>
> []s
>
> Chiappa
>
--------------------------------------------------------------------------------------------------------------------------
Atenção! As mensagens deste grupo são de acesso público e de inteira
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________
Moderador e Fundador: Dorian Anderson Soutto [EMAIL PROTECTED]
__________________________________________________________________
Yahoo! Grupos, um serviço oferecido por:
PUBLICIDADE
------------------------------------------------------------------------------
Links do Yahoo! Grupos
a.. Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
b.. Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
c.. O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço
do Yahoo!.
[As partes desta mensagem que não continham texto foram removidas]
--------------------------------------------------------------------------------------------------------------------------
Atenção! As mensagens deste grupo são de acesso público e de inteira
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________
Moderador e Fundador: Dorian Anderson Soutto [EMAIL PROTECTED]
__________________________________________________________________
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
<*> Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
