El usuario creado puede acceder a todas las bases de datos en PostgreSQL sin ninguna concesión

44

Debo estar perdiendo algo con respecto a la configuración de PostgreSQL. Lo que me gustaría hacer es crear múltiples bases de datos y usuarios que estén aislados unos de otros para que un usuario específico solo tenga acceso a las bases de datos que especifique. Sin embargo, por lo que puedo determinar, cualquier usuario creado tiene acceso a todas las bases de datos sin que se otorguen subvenciones específicas.

Esto es lo que hago en un Ubuntu Server 12.04:

apt-get install postgresql
sudo -u postgres createuser -DRSP mike1 (Especificando la contraseña para el nuevo usuario)
sudo -u postgres createdb data1
psql -h localhost -U mike1 data1 (Especificando la contraseña para que el usuario mike1 inicie sesión)

Parece que el nuevo usuario "mike1" no tiene problemas para conectarse a la base de datos "data1" y crear tablas, etc. Y esto sin ejecutar ningún comando GRANT (y el propietario de "data1" es "postgres" ya que no especifiqué un propietario en el paso 3). ¿Es así como se supone que funciona?

Lo que me gustaría hacer es otorgar a mike1 acceso completo a los datos1 y luego repetir esto para más usuarios y bases de datos, asegurándome de que los usuarios solo tengan acceso a una (o posiblemente a varias) bases de datos de mi elección.

postgresql permissions

— microplaca
fuente

1

Tenga en cuenta que incluso si un usuario está limitado a una base de datos, aún puede consultar las tablas globales, lo que les permitirá ver la lista de nombres de bases de datos y la lista de usuarios.

— kgrittn

47

En el nivel SQL, cada usuario puede conectarse a una base de datos recién creada, hasta que se emita el siguiente comando SQL:

REVOKE connect ON DATABASE database_name FROM PUBLIC;

Una vez hecho esto, a cada usuario o rol que debería poder conectarse se le debe otorgar explícitamente el privilegio de conexión:

GRANT connect ON DATABASE database_name TO rolename;

Editar: en un escenario multiinquilino, connectse eliminaría más que solo el privilegio. Para obtener sugerencias y prácticas recomendadas para múltiples inquilinos, es posible que desee leer en la wiki pública postgresql: derechos compartidos de alojamiento y administración de bases de datos en PostgreSQL .

— Daniel Vérité
fuente

El valor predeterminado debería haber sido al revés. Quiero crear un usuario con una contraseña generada aleatoriamente y otorgarle acceso a una única base de datos, sabiendo que postgrespuede acceder a todas las bases de datos.

— TheRealChx101

24

PUBLIC tiene acceso a la base de datos de manera predeterminada, pero no puede acceder a los datos. Puedes revocar al público:

REVOKE CONNECT ON DATABASE your_database FROM PUBLIC;

Si desea esta configuración para todas las bases de datos futuras, revoque CONNECT en la base de datos template1 (base de datos de plantilla predeterminada para crear una nueva base de datos):

REVOKE CONNECT ON DATABASE template1 FROM PUBLIC;

— Frank Heikens
fuente

Veo. Ahora tiene más sentido. Supongo que no debería venir aquí como un recién llegado a PostgreSQL y discutir que tal vez PUBLIC no debería tener el privilegio CONNECT en template1 como predeterminado :) Pero ahora también veo que los datos nunca estuvieron en peligro. ¡Gracias!

— mikeplate

1

Eres más que bienvenido como recién llegado, también para disputar la configuración. ¡Todos pueden aprender de eso!

— Frank Heikens

1

En realidad, ese privilegio CONNECT no se pasa de la plantilla a la nueva base de datos, por lo que revocarlo en template1 no tiene el efecto mencionado.

— Daniel Vérité

2

@ DanielVérité Ya veo. Así que supongo que la solución es siempre recordar y hacer REVOKE CONNECT al crear una nueva base de datos. ¿Realmente es así como lo hacen los administradores de PostgreSQL, o no debería importarme tanto ya que los datos no están accesibles de todos modos? Aún así, creo que una lista de tablas puede revelar información innecesaria para futuros ataques, aunque solo sea entre usuarios ya autorizados en un entorno multiinquilino. Además: me di cuenta de que public también puede crear sus propias tablas en cualquier base de datos que no haya sido REVOKE CONNECT. Me parece un poco extraño tenerlo por defecto, debo decir.

— Mikeplate

1

Si. Estoy agregando enlaces relacionados a mi respuesta, es posible que desee leer un par de documentos más sobre eso.

— Daniel Vérité

4

Además de revocar los privilegios de conexión de PUBLIC de manera predeterminada, y otorgarlos como se desee específicamente, el otro nivel en el que puede controlar el acceso es a través del archivo pg_hba.conf.

Puede encontrar dónde se almacena el archivo con:

SHOW hba_file;

Si elige utilizar este mecanismo, hay comentarios incrustados que pueden ser suficientes para comenzar. Los documentos están aquí:

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

— kgrittn
fuente

¡Gracias! Miré el archivo pg_hba.conf pero tenía la impresión de que solo gobierna cómo se autentica un usuario cuando se conecta a una base de datos y no qué privilegios tiene el usuario en esa misma base de datos.

— mikeplate

1

Un usuario solo puede conectarse a bases de datos según lo permitido por pg_hba.conf. Eso incluye no solo la combinación de usuario y base de datos, sino también el host desde el que se conectan y el método de autenticación permitido. Si no necesita esa granularidad de control, la técnica GRANT/ REVOKEdiscutida en otras respuestas probablemente sea más fácil. Por un lado, solo necesita una conexión de base de datos de superusuario para eso, en lugar de necesitar un inicio de sesión del sistema operativo que pueda editar el archivo.

— kgrittn

0

Encontré este hilo buscando una manera de evitar que los usuarios incluso enumeren los otros nombres de bases de datos. El REVOKE CONNECTno evita esto.

Según las respuestas a esta pregunta SO, no hay una forma (recomendable) de lograrlo.

— AdamAL
fuente