Re: RES: RES: RES: [oracle_br] Conceder permissao a todos objetod de
Oi Chiappa, agora eu peguei o seu raciocínio - a forma de implementar isso dependeria de inúmeras parafernálias tipo SQL dinâmico. Sobre a queda de performance de SQLs dinâmicos, eu nem preciso ir no Asktom. Eu já fiz muitos testes e comprovo o que vc diz em número, genero e grau. Mas siga o meu raciocínio e cenário. GRANT SELECT tabela TO role Quando vc dá GRANT role TO USER usuario, o acesso a tabela pelo usuário é automático, correto? Vc não precisa ter SQL dinâmicos ou qq outra parafernália para que o usuário passe a enxergar a tabela. Porque não existir o mesmo automatismo para um GRANT SELECT ON ANY TABLE to role? Repare que no meu caso hipotético, o usuário só irá consultar as tabelas: imagine, por exemplo, um Dataware House. Em ambientes muito dinâmicos, o processo de criação de tabelas é constante e muitas vezes não existe um AD só para ficar controlando isso. Se houvesse algo automático, vc teria uma tarefa a menos para dar a ele. Isso me lembra uma visita em uma empresa em que o prazo para criar um campo em uma tabela era de 1 mês Quando chegamos e começamos a criar uma tabela por dia (com seus respectivas telas de manutenção), o usuário pirou e passou a nos amar eternamente :))) Antes que me crucifixem por estas afirmações, recomendo a todos o livro Refactoring Database do Scott Ambler (o das metodologias ágeis) http://www.agiledata.org/essays/databaseRefactoring.html Sobre o Metalink: esse é um tema polêmico!!! Eu até teria verba para comprar mas não concordo com os termos da Oracle. É uma questão de principio. Se vc compra um produto Oracle, vc deveria ter automaticamente acesso ao Metalink sem ter que pagar a mais por isso. Até a Microsoft e a Apple que são os piores casos de desrespeito ao consumidor tem seus equivalentes de Metalink abertos para quem compra os produtos deles. Por isso, eu pago R$10mil a um consultor mas não pago R$3mil pelo Metalink. Um abraço, Josir. O porquê de não ser a melhor opção, em primeiro lugar é por que pra implementar isso vc VAI TER QUE, como eu disse, criar triggers/jobs que criem SQLs dinâmicos com DDL, e há imposto de performance se houver abuso tanto para SQL dinâmico (parses extras) quanto para DDLs [As partes desta mensagem que não continham texto foram removidas]
Re: RES: RES: RES: [oracle_br] Conceder permissao a todos objetod de
Sim Josir, principalmente o custo em performance pra se implantar esse tipo de admin é que me leva à contra-recomendá-lo. No seu argumento, a primeira coisa é que SELECT ANY é um exemplo infeliz, ANY significa ** QUALQUER ** uma no banco de dados, evidentemente INCLUINDO as tabelas internas do SYS - que ÓBVIO possuem senhas, códigos SQL recursivos do banco e muitas outras cositas más, nem preciso dizer mais pra se perceber que ROMBO de segurança potencial pode ser SELECT ANY TABLE na mão de usuário final... Assim, suporei que na verdade o que vc queria dizer é SELECT em um nível acima de tabelas, em algo que AGRUPE tabelas, o que poderia ser um SCHEMA (como citado na thread) ou uma TABLESPACE, ambos podem possuir n tabelas internamente, são agrupadores naturais de tabelas. Tecnicamente penso que não haveria nenhum grande impedimento pra Oracle implementar algo do tipo, sei inclusive que na pesquisa de new features quea Oracle sempre faz a cada release isso tinha sido citado, e na thread http://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:48704116042682#49132370956407 também havia - acho então que ela não fez porque foi considerada uma feature de raro uso, o número de usuários que pediram issso, que precisavam disso deve ter sido inferior à de outras... Na minha experiência mesmo isso aconteceu, já que via de regra, num sistema COM PREOCUPAÇÔES de segurança, NÂO È regra que qualquer um possa ler qualquer informação, NECESSARIAMENTE há várias e várias tabelas onde há apenas uma porção dos registros que uma pessoa pode ler, há várias a várias tabelas que não podem ser lidas por qquer um, enfim, há ** muito MAIS ** tabelas que não são públicas do que tabelas públicas... E mesmo esse conceito de públicas eu questiono, afinal um database em tese serve (ou pode servir) a MAIS DE UM APLICATIVO, se vc tiver um automatismo desses implantado isso implica que não só qualquer um, mas QUALQUER aplicativo pode ler, não me parece uma situação comum, segura e estabelecida isso Isso também tem relação com PERFORMANCE, pois uma tabela pública desse tipo ** implica ** que qualquer um pode fazer qualquer tipo de SELECT retornando qualquer qtdade de dados a qualquer hora - HUMMM, eu administro um DW, sabe vc quando eu vou deixar que a maioria das minhas tabelas (que são GRANDES, que EXIGEM que sejam especificados determinados campos no WHERE pra que seja usado eliminação de particionamento, etc) possam ser consultadas por qualquer um a qualquer hora ?? No dia que chover canivete aberto... E o ponto final contrário a automatismos do tipo é que eles são INCLUSIVOS, ie, vc passa a ter um default de DAR o privilégio antes mesmo que a pessoa precise, ao invés de trabalhar com o conceito de PRIVILÈGIOS MÍNIMOS, isso torna MUITO MAIS FÁCIL imho o DBA esquecer de programar as exceções e nenguinho acabar recebendo o que não precisa/não pode, já que sem fazer nada todo mundo já recebe privs automagicamente... NO caso do teu cliente onde levava um Mês pra adicionar uma coluna isso é TÃO CASO DE MÁ ADMINISTRAÇÂO quanto o caso onde isso é feito num zás-trás, SEM análise de segurança, SEM análise de performance (sim, novas colunas PODEM influenciar o CBO...), ambos simplesmente são reversos do mesmo caso de má-admin Se máxima performance, máxima segurança e mínimo desperdício (evitando se adicionar a mesma coluna com mesma info em vários lugares, ou com datatypes diferentes/não ótimos) são desejados, há ** SIM ** que se ter um DA e/ou um DBA que vão SIM levar um pouco de tempo pra fazer a análise adequada, isso é INVESTIMENTO (perde-se um pouco de tempo MAS ganha-se confiabilidade), só não pode ser algo resvalando pro absurdo como o caso citado... Sobre o metalink : ok, entendo o seu ponto, só o que digo é sejamos contra ou a favor o fato é que NÂO é essa a política da Oracle, E SE vc (por princípios ou o que for) não investir os mil reais mínimos que mais ou menos custariam um acesso ao menos de consulta no metalink, ** não só ** vc vai pagar (e mais de uma vez!!) dez vezes isso pra um consultor, mas também VAI (por falta de acesso ao database de bugs) cair em bugs que vão te fazer perder tempo e dinheiro, NÂO VAI usar determinadas features em modo top de otimização (pois é quase só no metalink que vc acha artigos importantes sobre algumas feaures), NÃO VAI receber algumas recomendações e soluções de casos que só lá existem caso seja assim que vc vai administrar ok, nada contra, só fique ciente do ônus que vc vai incorrer. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Josir Gomes [EMAIL PROTECTED] escreveu Oi Chiappa, agora eu peguei o seu raciocínio - a forma de implementar isso dependeria de inúmeras parafernálias tipo SQL dinâmico. Sobre a queda de performance de SQLs dinâmicos, eu nem preciso ir no Asktom. Eu já fiz muitos testes e comprovo o que vc diz em número, genero e grau. Mas siga o meu raciocínio e cenário. GRANT SELECT tabela TO role Quando vc dá GRANT role TO USER
RES: RES: RES: [oracle_br] Conceder permissao a todos objetod de UM schema
Então Chiappa, o uso de INVOKER RIGHTS não é para eu executar o corpo da procedure com as permissões do usuário logado e não com usuário que eh o owner da procedure?? Por default ele pega as permissões do owner.. Tem alguma forma de eu habilitar para que os grants das roles funcionem como explícitos??? Bom o site que vi que isso era um bug é esse aqui: http://www.imasters.com.br/forum/lofiversion/index.php/t206115.html atenciosamente, Renan Nucci Desenvolvedor C# CSM Software Msn: [EMAIL PROTECTED] De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de jlchiappa Enviada em: sexta-feira, 20 de julho de 2007 18:24 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: RES: [oracle_br] Conceder permissao a todos objetod de UM schema Renan, obviamente o .BAT *** não sabe *** nada vezes nada a respeito de linguagem SQL, de PL/SQL, de banco, ele NÂO é parte do banco nem foi feito pela Oracle... Só o que ele sabe é processar comandos próprios e/ou chamar executáveis, o que ocorre é que quem SABE executar SQLs e PL/SQLs é o sql*plus, que é SIm um programa executável e portanto pode ser executado a partir do BAT... A sequ~encia portanto é o .BAT chama o sqlplus que executa a tua rotina , ok ? Isso eu cito como complemento do seu conhecimento, já que vc não vai usar o BAT , pelo que diz, então tá... No caso de procedure, rigorosamente NÂO, esse comportamento NÃO É BUG, é o comportamento default DOCUMENTADO NO MANUAL DE DESENVOLVEDORES, como citado em http://asktom.oracle.com/tkyte/Misc/RolesAndProcedures.html, quem te falou que é bUG falou uma asneira sem tamanho... Diga aí que site que é esse, que a gente já marca como fonte de DESinformação... Como citado no link, o fato é que no default quando vc cria um stored PL/SQL (seja procedure, function, package ou trigger) as roles são DESABILITADAS durante a execução, o GRANT precisar ser direto, OU em alguns casos vc pode mudar o default da identificação de privs dentro do seu stored PL/SQL, veja no manual de PL/SQL sobre INVOKER RIGHTS. []s Chiappa --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br , Renan Nucci - CSM Software [EMAIL PROTECTED] escreveu Clayton, o bat eu sei fazer, o q não sei eh fazer a chamada a ele sem ser pelo SQL plus... mas acho q não vou precisar fazer o bat.. Chiappa, essa solucao que vc me ofereceu eu estava escrevendo ela quando vc mando... pelo menos estou pensando como os grandes.. RSS Agora estou me deparando com um problema de privilégios.. Eu executando esse GRANT dentro da procedure eu recebo uma mensagem de erro alegando privilégios insuficientes, mas executando por fora dela eu consigo na boa... Este teste estou fazendo com o usuário que eh dono da procedure.. Andei vendo sobre este erro e vi um site dizendo que eh um bug do Oracle, que não reconhece as permissões vindas de um role e somente as explicitas ao user.. isso se confirma?? atenciosamente, Renan Nucci Desenvolvedor C# CSM Software Msn: [EMAIL PROTECTED] 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 Clayton Rocha Enviada em: sexta-feira, 20 de julho de 2007 14:57 Para: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br Assunto: RES: RES: [oracle_br] Conceder permissao a todos objetod de UM schema O que você pode fazer é um arquivo BAT que executa automaticamente esse script... te resolve a situação? Sabe fazer? Quer ajuda? []'s Clayton De: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br ] Em nome de Renan Nucci - CSM Software Enviada em: sexta-feira, 20 de julho de 2007 14:35 Para: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br Assunto: RES: RES: [oracle_br] Conceder permissao a todos objetod de UM schema Eu não tinha conhecimento dos comandos que me foi passado tive de dar uma pesquisada para ver o que fazem.. Eu só consigo executar esse procedimento via SQL Plus? Não tem outra forma de adicionarmos permissão para um schema inteiro então? atenciosamente, Renan Nucci Desenvolvedor C# CSM Software Msn: [EMAIL PROTECTED] mailto:renanxr3%40hotmail.com mailto:renanxr3%40hotmail.com De: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br ] Em nome de jlchiappa Enviada em: sexta-feira, 20 de julho de 2007 13:12 Para: oracle_br@yahoogrupos.com.br mailto:oracle_br
Re: RES: RES: RES: [oracle_br] Conceder permissao a todos objetod de
Chiappa, me interessei pelo post :) 1) Vc podia dissertar sobre o porque não se deve administrar a segurança dessa forma. Se um grupo de usuários tiver sempre direito a SELECT em uma base, porque não utilizar o fictício: GRANT SELECT ON [schema] to [role] Acho que isso tá mais para uma limitação do Oracle (facilmente contornável, eu sei, mas ainda assim uma limitação). 2) Como eu não tenho acesso ao Metalink, vc poderia falar mais sobre esse artigo How to Automate Grant Operations When New Objects Are Created in a SCHEMA/DATABASE ? Um abraço, Josir. - Não, não tem GRANTs a nível de schema, não é assim que se deve administrar segurança num bd Oracle. Porém, apenas para complementar, o que ele em tese ** PODE ** sim fazer pra obter um automatismo do tipo, se for o caso, poderia ser: a) ter uma TRIGGER que após o DDL de criação do objeto faz o GRANT (como triggers de DDL tem restrições à SQL dinâmico, usar uma tabela de jobs cfrme mostrado na nota 210693.1 How to Automate Grant Operations When New Objects Are Created in a SCHEMA/DATABASE do Suporte Oracle/metalink
Re: RES: RES: RES: [oracle_br] Conceder permissao a todos objetod de
O porquê de não ser a melhor opção, em primeiro lugar é por que pra implementar isso vc VAI TER QUE, como eu disse, criar triggers/jobs que criem SQLs dinâmicos com DDL, e há imposto de performance se houver abuso tanto para SQL dinâmico (parses extras) quanto para DDLs (invalidação de objs, etc), e rotina automática vai ser executada SEMPRE, é porta aberta pra abusos... Pesquise em asktom.oracle.com para refs e exemplos de DDLs e SQLs dinãmicos em relação à queda de performance. O segundo ponto é em relação à Administração, inicialmente não me entra que possa haver segurança AUTOMÁTICA, ie, sem que nem o DBA nem o DA analisem a tabela recém-criada já seria automaticamente liberado SELECT ou o que for... Além disso, em vc tendo um schema/usuário dono da aplicação é um schema só que vc tem que proteger a senha, é um schema só que vc tem que auditar diferentemente... Aliás, no caso lá de DBA e DA analisarem CADA criação/alteração em Produção é ** crítico ** se vc quer Máxima segurança e Máxima performance, e procedimentos automágicos do tipo sempre me parecem vias de escape á isso... São basicamente estas as razões do meu conselho. Quanto à nota, antes de a citar uma dica : como já referido algumas vezes aqui no Grupo mesmo, vc pode obter acesso a QUALQUER dos textos do metalink registrando/suportando qquer produto Oracle, até o mais baratinho deles - assim, se vc ainda não tem nem sequer acesso aos textos do metalink, dada a ENORME importância de se ter acesso à isso, eu recomendo FORTEMENTE que vc tente obter,explique a quem de direito, recomendo esse (pequeno!) investimento pro teu patrão, há documentos ali que por si só resolvem problemas dificílimos no banco, que dão dicas PRECIOSAS, eu considero o metalink como parte da Documentação do banco... Na nota a idéia básica é a seguinte : quando uma trigger de DDL dispara (ao menos no 9i, não testei no 10g mas creio que é o mesmo) vc ** não ** recebe nas variáveis de sistema da trigger o SQL exato mas recebe um evento dizendo se é CREATE ou o que foi o DDL, e recebe o owner, tipo e nome do objeto sendo DDLzado - o procedimento é vc inserir essas infos numa tabela sua e imediatamente após disparar um job Oracle que leia a tabela e faça o GRANT : no exemplo da nota ele ainda resgata o SQL completo na V$SQL e derivadas, mas no caso discutido no grupo o que o colega lá queria é uma lógica simples, se é CREATE e o owner (schema) é X, então faça um GRANT SELECT pra uma determinada lista fixa de usuários (ou mais adequadamente pra uma role), pra essa lógica simplesm acho que o passo de recuperar o SQL é dispensável... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Josir Gomes [EMAIL PROTECTED] escreveu Chiappa, me interessei pelo post :) 1) Vc podia dissertar sobre o porque não se deve administrar a segurança dessa forma. Se um grupo de usuários tiver sempre direito a SELECT em uma base, porque não utilizar o fictício: GRANT SELECT ON [schema] to [role] Acho que isso tá mais para uma limitação do Oracle (facilmente contornável, eu sei, mas ainda assim uma limitação). 2) Como eu não tenho acesso ao Metalink, vc poderia falar mais sobre esse artigo How to Automate Grant Operations When New Objects Are Created in a SCHEMA/DATABASE ? Um abraço, Josir. - Não, não tem GRANTs a nível de schema, não é assim que se deve administrar segurança num bd Oracle. Porém, apenas para complementar, o que ele em tese ** PODE ** sim fazer pra obter um automatismo do tipo, se for o caso, poderia ser: a) ter uma TRIGGER que após o DDL de criação do objeto faz o GRANT (como triggers de DDL tem restrições à SQL dinâmico, usar uma tabela de jobs cfrme mostrado na nota 210693.1 How to Automate Grant Operations When New Objects Are Created in a SCHEMA/DATABASE do Suporte Oracle/metalink
