Quais os cuidados a ter quando trabalhar com GRANT / REVOKE / ROLE

Versão para impressãoEnviar para amigoVersão PDF
  • 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.

4
Média: 4 (2 votos)
Sua avaliação: Nenhum

usuário

Boa tarde.... Tenho tido um problema com o PUBLIC na versão IDS 7.2 INFORMIX, qualquer usuário novo criado herda os privilégios do user PUBLIC, como proceder para que o novo usuário não tenha tais privilegios. Preciso ter privilegios independentes para novos usuários tais como leitura ... No aguardo, obrigado......!!!

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

O conteúdo deste campo é privado não será exibido ao público.
  • Endereços de páginas de internet e emails viram links automaticamente.
  • Você pode usar tags BBCode no texto.
  • Tags HTML permitidas: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>

Mais informações sobre as opções de formatação

CAPTCHA
Este teste é para bloquear programas automatizados e previnir spams
CAPTCHA de Imagem
Digite o texto exibido na imagem.