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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.