Continua ** sim ** sendo necessário dar privilégios, veja vc : o que esse comando faz é setar o schema default onde um dado objeto vai ser procurado, uma vez encontrado pra ser acessado o objeto o usuário CONTINUA necessitando de ter recebido privilégio adequado... É assim : suponha que o usuário SCOTT quer acessar uma tabela do usuário X, além de ter os privilégios, normalmente ele teria que referenciar o schema-destino na frente, tipo :
SELECT X.nomedatabela ..... SE esse usuário emitir um : ALTER SESSION SET CURRENT_SCHEMA=X; quando ele fizer um SELECT nomedatabela apenas, o banco vai procurar esse nomedatabela no schema X por default, mesmo não sendo especificado no SQL, é isso. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto <[EMAIL PROTECTED]> escreveu > > No caso do ALTER SESSION SET CURRENT SCHEMA, não é necessário dar os > privilégios para > os outros usuários, ou os privilégios deverão ser dados mesmo assim? > > Thiago. > > Anderson Haertel Rodrigues - FLN escreveu: > > > Claro, Chiappa, opiniões e conselhos cada um tem o seu............ > > > > Mas, até momento apenas sei que eles podem dar problemas de > > performance, como mostrado nos links abaixo. Ainda não me incomodei > > com eles, mesmo em sistemas grandes e com o quesito performance alto > > (quem sabe um dia eu me depare com isso)...... ;-) > > > > Penso que sinônimos públicos são uma mão na roda para as aplicações, > > uso constantemente.... > > > > Um abraço! > > > > Atenciosamente, > > > > Anderson Haertel Rodrigues > > Administrador de Banco de Dados > > Florianópolis/SC - [EMAIL PROTECTED] > > <mailto:anderson_hr_listas%40yahoo.com.br> > > > > -----Mensagem original----- > > De: oracle_br@yahoogrupos.com.br > > <mailto:oracle_br%40yahoogrupos.com.br> > > [mailto:oracle_br@yahoogrupos.com.br > > <mailto:oracle_br%40yahoogrupos.com.br>]Em nome de jlchiappa > > Enviada em: quarta-feira, 22 de novembro de 2006 12:23 > > Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br% 40yahoogrupos.com.br> > > Assunto: Re: RES: [oracle_br] Segurança > > > > Eu vou dar um conselho diferente : eu *** ABOMINO *** sinônimos > > públicos, não só pelos problemas de performance mostrados em > > http://www.ixora. > > <http://www.ixora.com.au/newsletter/2001_05.htm#synonyms > > <http://www.ixora.com.au/newsletter/2001_05.htm#synonyms>> > > com.au/newsletter/2001_05.htm#synonyms e comentados > > também em http://www.ixora. <http://www.ixora.com.au/q+a/library.htm > > <http://www.ixora.com.au/q+a/library.htm>> com.au/q+a/library.htm (e > > que óbvio variam > > de acordo com a versão de banco, se usado cache de cursors, etc), MAS > > pela muito simples razão que eles COMPLICAM a lógica de controle, > > público é público, é de TODOS EM ABSOLUTO, assim sendo até o usuário > > mais zemanérasteiro, pra quem vc NÃO deu e NÃO quer dar acesso, ainda > > assim teria o sinônimo, aí uma busca na ALL_OBJECTS ou similar ia > > mostrar linhas a que o cara não tem privilégio real, abomino isso... > > Então, imho, os sinônimos públicos NÃO ESTÃO atendendo se o objetivo > > é ter a melhor performance e a melhor administração possível... > > Minha recomendação : já que vc vai ter MESMO que alterar por outras > > coisas, passe a usar OU sinônimos PRIVADOS, OU (o que não é nada mau > > também) alterar o CURRENT_SCHEMA via triger de logon, esta última é > > interessante porque TODOS OS SQLs assim passarão a ser executados > > numa única conta, num único domain space, que é o do usuário dono das > > tabelas (que é quem dará os privilégios e é quem será acessado via > > CURRENT_SCHEMA), http://asktom. <http://asktom.oracle.com/pls/ask/f? > > <http://asktom.oracle.com/pls/ask/f?>> oracle.com/pls/ask/f? > > p=4950:8:::::F4950_P8_DISPLAYID:7452932520496 tem um exemplo. > > E é claro, nem preciso falar que o caminho que vc está pensando é > > imho o ** único ** viável se vc quer mesmo ter alguma > > segurança/capacidade de auditoria, permissões PÚBLICAS ou de ANY > > qualquer coisa são furos de segurança do tamanho de um Boing 707... > > > > []s > > > > Chiappa > > > > --- Em [EMAIL PROTECTED] <mailto:oracle_br% 40yahoogrupos.com.br> > > os.com.br, "Anderson Haertel Rodrigues - > > FLN" <anderson.rodrigues@> escreveu > > > > > > Thiago, > > > > > > Eu faria o que você está planejando fazer. Blz? > > > > > > Agora, no que os Sinônimos Públicos que te incodam? > > > Já que os mesmo estão funcionando hoje e se você não mexer nisso é > > menos impacto. > > > > > > Atenciosamente, > > > > > > Anderson Haertel Rodrigues > > > Administrador de Banco de Dados > > > Florianópolis/SC - anderson_hr_listas@ > > > > > > > > > > > > -----Mensagem original----- > > > De: [EMAIL PROTECTED] <mailto:oracle_br%40yahoogrupos.com.br> > > os.com.br > > [mailto: [EMAIL PROTECTED] <mailto:oracle_br% 40yahoogrupos.com.br> > > os.com.br]Em nome de Thiago Lazzarotto > > > Enviada em: quarta-feira, 22 de novembro de 2006 07:47 > > > Para: [EMAIL PROTECTED] <mailto:oracle_br% 40yahoogrupos.com.br> > > os.com.br > > > Assunto: [oracle_br] Segurança > > > > > > > > > > > > Bom dia Senhores. > > > Gostaria de algumas dicas dos amigos da lista. > > > > > > Estou implementando algumas melhorias básicas no nosso banco de > > dados > > > no que se refere a segurança. > > > > > > Cenário Atual: > > > - Todos os usuários possuem uma role que dá direito a UPDATE, > > DELETE e > > > INSERT any table. (terrível) > > > - Para todas as tabelas desejadas, é dado um grant SELECT to > > PUBLIC. > > > (péssimo) > > > - Para todos os objetos são criados sinonimos públicos. > > > > > > Para onde estou caminhando: > > > - Criação de roles conforme área de negócio da empresa. > > > - Dar privilégios específicos para cada uma das roles. > > > > > > Minha dúvida está nos sinonimos. > > > O que vcs acham: criamos sinonimos por usuario ou mantemos os > > sinonimos > > > publicos? > > > Pensei em nao usar sinonimo, e usar o ALTER SESSION SET CURRENT > > SCHEMA, > > > mas é meio complicado. > > > A nao ser que fosse por uma TRIGGER de logon. > > > > > > Obrigado. > > > Thiago. > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
