Re: [firebase-br] "DO SUSPEND"
Gladiston Santana via lista <[email protected]>
| Newsgroups | gmane.comp.db.firebase.portuguese |
|---|---|
| Message-ID | <CALv8-NN+L583-Tj9jtdWR-h+d4UTxggcJGDO_0EEjy5EZV1V5Q@mail.gmail.com> |
Imagine uma procedure chamada SP_CRUD_CLIENTES que faz insert/update/delete na tabela 'CLIENTES' também faz um insert/update/delete em 'CLIENTES_CONTATOS' e também um SELECT na tabela 'CNPJ' que refere-se a situação cadastral no órgão federal. Pois bem, você usa o SYSDBA pq ele tem acesso a tudo, mas se fizer tudo com o SYSDBA sua aplicação perde o controle de quem fez alterações e no quê. O que eu recomendei é ao criar procedures dar um 'autogrant', isto é, dizer para o banco que a procedure SP_CRUD_CLIENTES por si mesma tem acesso as tabelas que ela usará, assim: GRANT ALL ON CLIENTES TO PROCEDURE SP_CRUD_CLIENTES GRANT ALL ON CLIENTES_CONTATOS TO PROCEDURE SP_CRUD_CLIENTES GRANT SELECT ON CNPJ TO PROCEDURE SP_CRUD_CLIENTES Ferramentas como o IBEXPERT fazem isso sem ter que digitar na unha toda vez que uma procedure é criada ou modificada. Agora que uma procedure tem acesso a esses objetos, então você dá acesso a um usuário comum a procedure: GRANT EXECUTE ON PROCEDURE CRUD_CLIENTES TO MARIO [WITH GRANT OPTION]; Se todos terão acesso a procedure, dá para simplificar: GRANT EXECUTE ON PROCEDURE CRUD_CLIENTES TO PUBLIC; Foi isso que eu quiz dizer. Quando você faz o 'autogrant', você faz apenas 1 vez. Depois disso é necessário apenas relacionar GRANT EXECUTE para cada usuário que usufruir da procedure. Sem o 'autogrant', teria de repetir GRANT para cada usuário a procedure e também aos objetos citados dentro da SP, o que ficaria muito trabalhoso e é por isso que você tem usado o SYSDBA para não ter que se preocupar com os GRANTs. Essa é a forma mais pratica sem usar ROLES. Se entender o processo acima, você simplifica ainda mais usando ROLES. Você não precisa saber quem criou as tabelas para operar com os grants, mas provavelmente usará em suas procedures 'current_user' para saber quem esta conectado e fazer insert/update/delete em colunas como 'last_owner' ou arquivos de logs. PS: Por favor, se sua mensagem for para o grupo não remova o nome da lista. Se o assunto mudar, crie uma nova mensagem. Em ter., 14 de nov. de 2023 às 10:21, Mário Reis <[email protected]> escreveu: > Bom dia/tarde Gladiston, > Estou a seguir o V/ conselho de não dar permissões aos users e ao tentar > revok para o ADM (um user muito velho que uso quase desde de sempre) recebo > esta mensagem > mega estranha: > SYSDBA is not grantor of INSERT on IBUCTABUSERSLOGGED to ADM. SQL Code: > -607 IB Error Number: 335544351 > Ora o [IB ]UCTABUSERSLOGGED é o mesmo que o UCTABUSERSLOGGED do USers > Control Component e a tabela foi(são) criado automaticamente a primeira vez > que se entra > na aplicação com o UCUSERS Control activo. > Não sendo o SYSDBA, como posso saber onde posso ver quem foi o "USER" > criou estas tabelas !? Obrigado > > ______________________________________________ FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107 Para consultar mensagens antigas: http://www.firebase.com.br/pesquisa_lista.html