O usuário criado pode acessar todos os bancos de dados no PostgreSQL sem nenhuma concessão

44

Devo estar faltando alguma coisa com relação à configuração do PostgreSQL. O que eu gostaria de fazer é criar vários bancos de dados e usuários isolados um do outro, para que um usuário específico tenha acesso apenas aos bancos de dados especificados. No entanto, pelo que posso determinar, qualquer usuário criado tem acesso a todos os bancos de dados sem conceder nenhuma concessão específica.

Aqui está o que eu faço no Ubuntu Server 12.04:

apt-get install postgresql
sudo -u postgres createuser -DRSP mike1 (Especificando a senha para o novo usuário)
sudo -u postgres createdb data1
psql -h localhost -U mike1 data1 (Especificando a senha para o usuário mike1 efetuar login)

Parece que o novo usuário "mike1" não tem problemas para conectar-se ao banco de dados "data1" e criar tabelas etc. E isso sem executar nenhum comando GRANT (e o proprietário do "data1" é "postgres", pois não especifiquei um proprietário na etapa 3). É realmente assim que deve funcionar?

O que eu gostaria de fazer é conceder ao mike1 acesso total aos dados1 e repetir isso para mais usuários e bancos de dados, certificando-se de que os usuários tenham acesso apenas a um (ou possivelmente a vários) bancos de dados de minha escolha.

postgresql permissions

— mikeplate
fonte

1

Lembre-se de que, mesmo que um usuário esteja limitado a um banco de dados, ele ainda poderá consultar as tabelas globais, o que permitirá ver a lista de nomes de banco de dados e a lista de usuários.

— kgrittn

47

No nível SQL, todo usuário pode realmente se conectar a um banco de dados recém-criado, até que o seguinte comando SQL seja emitido:

REVOKE connect ON DATABASE database_name FROM PUBLIC;

Uma vez feito, cada usuário ou função que deve poder se conectar deve receber explicitamente o privilégio de conexão:

GRANT connect ON DATABASE database_name TO rolename;

Editar: em um cenário de vários inquilinos, mais do que apenas o connectprivilégio seria removido. Para obter dicas e práticas recomendadas para a multilocação, leia o wiki público do postgresql: Hospedagem de banco de dados compartilhado e gerenciamento de direitos no PostgreSQL .

— Daniel Vérité
fonte

O padrão deveria ter sido o contrário. Desejo criar um usuário com uma senha gerada aleatoriamente e conceder acesso a um único banco de dados, sabendo que postgrespode acessar todos os bancos de dados.

— TheRealChx101 26/07

24

PUBLIC tem acesso ao banco de dados por padrão, mas não pode acessar os dados. Você pode REVOGAR o PÚBLICO:

REVOKE CONNECT ON DATABASE your_database FROM PUBLIC;

Se você deseja essa configuração para todos os bancos de dados futuros, revogue CONNECT no banco de dados template1 (banco de dados de modelo padrão para criar um novo banco de dados):

REVOKE CONNECT ON DATABASE template1 FROM PUBLIC;

— Frank Heikens
fonte

Eu vejo. Agora faz mais sentido. Eu acho que não deveria vir aqui como um novato no PostgreSQL e contestar que talvez PUBLIC não deva ter o privilégio CONNECT no template1 como padrão :) Mas agora vejo também que os dados nunca estavam em risco. Obrigado!

— Mikeplate

1

Você é bem-vindo como novato, também para disputar configurações. Todo mundo pode aprender com isso!

— Frank Heikens

1

Na verdade, esse privilégio CONNECT não é passado do modelo para o novo banco de dados, portanto, revogá-lo no modelo1 não tem o efeito mencionado.

— Daniel Vérité

2

@ DanielVérité eu vejo. Portanto, acho que a solução é sempre lembrar e fazer o REVOKE CONNECT ao criar um novo banco de dados. É assim que geralmente é feito pelos administradores do PostgreSQL, ou não devo me importar tanto assim, já que os dados não estão acessíveis? Ainda assim, acho que uma lista de tabelas pode fornecer informações desnecessárias para ataques futuros, mesmo que apenas entre usuários já autorizados em um ambiente de vários locatários. Além disso: acabei de perceber que o público também pode criar suas próprias tabelas em qualquer banco de dados que não tenha sido REVOKE CONNECT. Parece um pouco estranho ter como padrão, devo dizer.

— Mikeplate

1

Sim. Estou adicionando links relacionados à minha resposta. Você pode ler mais alguns documentos sobre isso.

— Daniel Vérité

4

Além de revogar os privilégios de conexão do PUBLIC por padrão e concedê-los conforme desejado, o outro nível no qual você pode controlar o acesso é por meio do arquivo pg_hba.conf.

Você pode encontrar onde o arquivo está armazenado:

SHOW hba_file;

Se você optar por usar esse mecanismo, existem comentários incorporados que podem ser suficientes para você começar. Os documentos estão aqui:

http://www.postgresql.org/docs/current/interactive/auth-pg-hba-conf.html

— kgrittn
fonte

Obrigado! Eu observei o arquivo pg_hba.conf, mas fiquei com a impressão de que ele apenas governa como o usuário se autentica ao conectar-se a um banco de dados e não quais privilégios o usuário possui no mesmo banco de dados.

— Mikeplate #

1

Um usuário pode conectar - se apenas aos bancos de dados conforme permitido pelo pg_hba.conf. Isso inclui não apenas a combinação de usuário e banco de dados, mas também o host do qual eles estão se conectando e o método de autenticação permitido. Se você não precisar dessa granularidade de controle, a técnica GRANT/ REVOKEdiscutida em outras respostas provavelmente será mais fácil. Por um lado, você só precisa de uma conexão de banco de dados de superusuário para isso, em vez de precisar de um login do SO que possa editar o arquivo.

— kgrittn

0

Me deparei com esse segmento procurando uma maneira de impedir que os usuários listem os outros nomes de banco de dados. O REVOKE CONNECTnão impede isso.

De acordo com as respostas a esta pergunta do SO, não existe uma maneira (recomendável) de alcançá-lo.

— AdamAL
fonte