Início / dba / Perguntas / 73010
Accepted
Andomar
Asked: 2014-08-03 08:59:47 +0800 CST

Por que um novo usuário pode selecionar em qualquer tabela?

  • 772

Quando crio um usuário no Postgres,

create user test with password 'test';

O usuário acaba conseguindo se conectar a todos os bancos de dados da instância. O usuário também pode selecionar em qualquer tabela:

# psql -h localhost testdb test
Password for user test: *****
psql (8.4.20, server 9.1.13)
WARNING: psql version 8.4, server version 9.1.
         Some psql features might not work.
Type "help" for help.

testdb=> select * from testtable;
 id
------------
      1
(1 row)

A \llistagem do banco de dados mostra que testdbtem arquivos Access privileges. Então, por que um usuário recém-criado pode se conectar a esse banco de dados?

O usuário "teste" recém-criado também pode selecionar dados de tabelas. Por que ele pode fazer isso sem uma série grantde selectprivilégios?

Eu gostaria de criar um usuário que só pode se conectar a um banco de dados e apenas ler a partir de determinadas visualizações. Como posso impedir que um usuário leia diretamente das tabelas?

postgresql postgresql-9.1

2 respostas

  1. Também abordando a questão nos comentários.

    Funçãopublic

    Por documentação:

    A palavra-chave PUBLICindica que os privilégios devem ser concedidos a todas as funções, incluindo aquelas que podem ser criadas posteriormente. PUBLIC pode ser pensado como um grupo definido implicitamente que sempre inclui todas as funções .

    Ênfase em negrito minha. A associação publicnão pode ser revogada (ou concedida). Você só pode revogar privilégios de public. No seu caso, para bloquear todas as funções sem privilégios explícitos, como @Robert já forneceu :

    REVOKE ALL ON DATABASE testdb FROM PUBLIC;

    Funçãopostgres

    A função de banco de dados postgresé a superuserpor padrão. Você pode tirar isso postgres- mas isso seria imprudente: todos (incluindo alguns programas clientes) esperam postgresser um superusuário. Você também pode criar mais superusuários (cuidado com isso!). Os superusuários não precisam de privilégios. O manual mais uma vez :

    Deve-se observar que os superusuários do banco de dados podem acessar todos os objetos independentemente das configurações de privilégio do objeto. Isso é comparável aos direitos de root em um sistema Unix. Assim como o root, não é aconselhável operar como superusuário, exceto quando for absolutamente necessário.

    Quanto a sua pergunta:

    É verdade que se \lou \dn+exibe privilégios de acesso vazios, é o mesmo quepostgres=UC/postgres, =UC/postgres

    Não exatamente.

    • Os privilégios são concedidos pelo proprietário ou um superusuário (ou uma função que recebeu o privilégio de fazê-lo). postgres=UC/postgressignificaria postgresconcedido, o que não é preciso para privilégios vazios, mas o efeito é o mesmo em uma instalação padrão.

    • No entanto, não publicobtém privilégios para novos esquemasCONNECT e apenas TEMP(pode criar tabelas temporárias) privilégios para bancos de dados por padrão, não o CREATEprivilégio (não pode criar esquemas). Isso seria algo como =UT/??de acordo com a lista de possíveis privilégios - o manual mais uma vez :

            r -- SELECT ("read")
        w -- UPDATE ("write")
        a -- INSERT ("append")
        d -- DELETE
        D -- TRUNCATE
        x -- REFERENCES
        t -- TRIGGER
        X -- EXECUTE
        U -- USAGE
        C -- CREATE
        c -- CONNECT
        T -- TEMPORARY
  arwdDxt -- ALL PRIVILEGES (for tables, varies for other objects)
        * -- grant option for preceding privilege

    Você pode alterar os privilégios padrão. Escrevi mais sobre isso na resposta relacionada mencionada nos comentários:

    Mas esses privilégios padrão só se aplicam a objetos criados depois que os padrões foram alterados. Então, o que significa uma entrada ACL vazia? O manual no catálogo do sistemapg_default_acl :

    Observe que quando uma entrada ACL em outro catálogo é nula, ela representa os privilégios padrão pré-configurados para seu objeto, não o que quer que esteja em pg_default_acl no momento.

    Ênfase em negrito minha.

    • 3
  2. Best Answer

    Para resolver a questão de por que o teste pode SELECTpartir de tabelas sem um GRANT, é porque você não executou explicitamente REVOKEa capacidade de se conectar ao(s) seu(s) banco(s) de dados a partir PUBLICde e, em seguida, executou explicitamente GRANTpara o seu testusuário:

    REVOKE connect ON DATABASE testdb FROM PUBLIC;
GRANT connect ON DATABASE testdb TO test;

    Uma vez feito isso, você faria REVOKE SELECTpara o usuário dentro desse banco de dados suas tabelas e outros itens que deseja impedir que o usuário acesse e, em seguida, explicitamente GRANT SELECTpara as visualizações.

    Observe que o usuário aqui também pode ser uma função, à qual vários usuários podem ser adicionados.

    • 2

relate perguntas