[firebase-br] "DO SUSPEND"

Gladiston Santana gladiston.santana em gmail.com
Terça Novembro 14 11:19:13 -03 2023


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 <mariodosreyx em gmail.com>
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
>
>


Mais detalhes sobre a lista de discussão lista