Entendo Chiapa, acontece que este procedimento é na base de desenvolvimento (e esta também é totalmente auditada). Obrigado, era a questão da procedure que ele usava mesmo...
________________________________ De: J. Laurindo Chiappa <jlchia...@yahoo.com.br> Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 27 de Julho de 2012 14:48 Assunto: [oracle_br] Re: acesso à role Só pra deixar Claro o tamanho da encrenca, abaixo segue um exemplo de um usuário simples, um zémané qualquer, que não é DBA, mas recebeu esse megapower privilégio de INSERT ANY , sendo capaz de fakear a Auditoria interna.... Alguém vê alguma dificuldade em esse usuário ser mal-intencionado e mandar esse INSERT num LOOP, talvez lotando a tablespace e provocando uma Negação de serviço ?????? E isso porque peguei uma tabela simples, há tabelas internas mais complexas e importantes que eu poderia bulir também, inserir um dado falso.... Eca.... Taí um caso aonde se pode citar um absoluto : usuário não-DBA que recebeu qquer privilégio ANY, pra mim de IMEDIATO leva à um banco Absolutamente Inseguro... O exemplo : C:\Windows\system32>set ORACLE_SID=O10GR2 C:\Windows\system32>set ORACLE_HOME=C:\O10GR2 C:\Windows\system32>set PATH=%ORACLE_HOME%\BIN;%PATH% C:\Windows\system32>sqlplus / as sysdba SQL*Plus: Release 10.2.0.5.0 - Production on Sex Jul 27 14:32:49 2012 Copyright (c) 1982, 2010, Oracle. All Rights Reserved. Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining Scoring Engine and Real Application Testing options SQL> create user zemane identified by zemane; Usußrio criado. SQL> grant create session to zemane; ConcessÒo bem-sucedida. SQL> grant insert any table to zemane; ConcessÒo bem-sucedida. SQL> exit Desconectado de Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining Scoring Engine and Real Application Testing options C:\Windows\system32>sqlplus zemane/zemane SQL*Plus: Release 10.2.0.5.0 - Production on Sex Jul 27 14:33:53 2012 Copyright (c) 1982, 2010, Oracle. All Rights Reserved. Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining Scoring Engine and Real Application Testing options SQL> insert into sys.aud$( 2 SESSIONID, 3 ENTRYID, 4 STATEMENT, 5 TIMESTAMP#, 6 ACTION#, 7 RETURNCODE) 8 values( 9 1, 10 1, 11 1, 12 sysdate, 13 1, 14* 1); 1 linha criada. SQL> commit; Commit concluÝdo. SQL> c.q.d. []s Chiappa --- Em mailto:oracle_br%40yahoogrupos.com.br, "J. Laurindo Chiappa" <jlchiappa@...> escreveu > > 99,99 % de chance : o teu usuário deve estar fazendo o INSERT > programaticamente, de dentro de um stored PL/SQL (seja procedure, function, > trigger ou package), e o default nessas situações é que as ROLEs sejam > desabilitadas, aí ele Perde o privilégio : SE for isso mesmo, ele deve > receber o privilégio de INSERT diretamente, não numa role... > > []s > > Chiappa > > OBS : nem preciso dizer, privilégios xx ANY TABLE valem para QUALQUER tabela > (ANY=qquer uyma), o que INCLUI tabelas internas do database, tabelas de > schemas usadas por outras aplicações... ÓBVIO que isso é um furo de segurança > do tamanhoi de um BONDE, ENORME, no meu banco é que isso não aconteceria, é > um privilégio POR DEMAIS PODEROSO para qquer usuário possuir - não é difícil > , intencionalmente ou não, quem recebeu um super-privilégio desses interferir > talvez Severamente no database... > > --- Em mailto:oracle_br%40yahoogrupos.com.br, Jales Jose Moraes <malphigjjm@> > escreveu > > > > Pessoal tenho um usuário reclamando que está sem acesso a uma tabela. > > Acontece que ele está atribuído a uma role em que esta role tem um GRANT > > INSERT ANY TABLE. > > > > Mas quando concedo acesso ao seu usuario individual funciona. > > > > Sabem por quê? > > > > [As partes desta mensagem que não continham texto foram removidas] > > > [As partes desta mensagem que não continham texto foram removidas]
