Quais os cuidados a ter quando trabalhar com GRANT / REVOKE / ROLE
- Para remover a permissão de DBA ou RESOURCE de um usuário basta executar um REVOKE, porém este revoke irá sempre colocar a permissão do usuário em CONNECT, sendo que se o desejo for tirar o acesso total do usuário é necessário remover om CONNECT também:
GRANT DBA TO cesar; REVOKE DBA TO cesar; REVOKE CONNECT TO cesar; - Quando o banco é criado em modo NÃO-ANSI, ao criar um objeto é dado permissões automaticamente para o usuário PUBLIC.
Exemplo:
-- considerando que em um banco está sendo utilizado o usuário "cmartins" -- com permissão de RESOURCE e/ou DBA (para assim poder ter permissão de -- criar objetos). CREATE TABLE TESTE(...); SELECT... FROM systabauth, systables...; ... teste cmartins public su-idx--- ... - Para contornar o problema acima, definir como padrão nas variáveis de ambiente dos usuários que tem acesso a criação de objetos a variavel NODEFDAC=yes ou executar manualmente:
REVOKE all on tabela_xyz FROM public; - Quando é dado permissões por colunas em SELECT e UPDATE , não pode existir grant de SELECT/UPDATE na tabela para o usuário em questão, se tiver estes grants sobrepõe as restrições por coluna, ou seja, quando executar um grant por coluna, sempre executar um REVOKE SELECT/UPDATE na tabela.
- Quando uma procedure é criada com o operador DBA ( CREATE DBA PROCEDURE ) sua execução é realizada com os privilégios do dono (owner) dela, ou seja, com privilégios de DBA.
Se é dado um grant para um usuário X executar uma procedure criada pelo usuário "informix" ou usuário DBA do banco de dados, todo o acesso feito dentro da procedure será com o privilégio do usuário "informix" ou DBA.
Para procedures criadas sem esta palavra chave ou por usuários, executam normalmente com o privilégio do usuário que a chamou.
ATENÇÃO: Existe um bug na versão 11.50 xC5 (e provavelmente nas versões anteriores) em que uma procedure criada por um usuário DBA é criada como se o operador DBA fosse passado, sendo assim qualquer usuário que executa-la terá a execução no nível de DBA. - Quando definido uma ROLE e suas permissões , ao um usuário ativar ela, as permissões já existentes para o usuário não são sobrescritas, ou seja, é mesclado as permissões da ROLE + Permissões do USUÁRIO.
- 767 leituras
usuário
RE: usuário
Olá João,
Não existe um meio de tirar o grant de "PUBLIC" para um único usuário.
Pense nele como a configuração padrão, independente de o usuário ter grant ou não para tal objeto.
Por exemplo, se é dado um GRANT de SELECT na tabela XYZ para o PUBLIC, todos os usuários, sem exceção, terão acesso de select, mesmo que eles não tenham o grant especifico de select.
Para resolver uma situação desta, na versão 7.2 , é preciso remover o grant do PUBLIC e então dar a permissão de SELECT *apenas* para os usuários que devem ter acesso a tabela. E aqueles usuários que você não quer que acesse a tabela, basta não dar a permissão de SELECT.
Porém , dependendo da quantidade de objetos e usuários, você vai ter um certo trabalho para administrar isto.
Comentar