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
>
