PostgreSQL: permiso denegado para relación

Estoy un poco confundido sobre la configuración de permisos en PostgreSQL.

Tengo estos roles:

                             List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 admin     | Superuser, Create role, Create DB, Replication | {}
 meltemi   | Create role, Create DB                         | {rails}
 rails     | Create DB, Cannot login                        | {}
 myapp     |                                                | {rails}

y bases de datos:

                                    List of databases
        Name         | Owner  | Encoding |   Collate   |    Ctype    | Access privileges 
---------------------+--------+----------+-------------+-------------+-------------------
 myapp_production    | rails  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 ...

el usuario myappno tiene problemas para consultar la myapp_productionbase de datos agregando y eliminando registros. También me gustaría meltemipoder consultar la misma base de datos. Por lo tanto, he creado un papel railsque posee la base de datos y de hecho tanto meltemiy myappmiembros de rails. Pero sigo teniendo permission denied for relationerrores. Meltemipuede ver el esquema pero no puede consultar la base de datos.

Acabo de notar (con \dtcomando) que myappes el propietario de las tablas:

             List of relations
 Schema |       Name        | Type  | Owner 
--------+-------------------+-------+-------
 public | events            | table | myapp
 public | schema_migrations | table | myapp
 ...
 public | users             | table | myapp
 ...

Las tablas se crearon a través de un ORM (migraciones ActiveRecord de Rails).

Sé que la autorización es muy diferente en PostgreSQL (a diferencia de MySQL y otros que he usado). ¿Cómo debo configurar mi base de datos para que diferentes usuarios puedan acceder a ella? Algunos deberían poder CRUDAR, pero otros solo podrían leer, etc.

Gracias por cualquier ayuda. Lo siento, sé que esta es una pregunta muy básica, pero no he podido encontrar la respuesta yo mismo.

— Meltemi
fuente

Acabo de escribir sobre esto en mi respuesta a Conceder derechos en la base de datos postgresql a otro usuario en ServerFault.

Básicamente, la mejor solución cuando tiene un solo usuario y desea otorgar a otros usuarios los mismos derechos es convertir a ese usuario en un grupo, crear un nuevo usuario con el mismo nombre que el miembro original del grupo, y concede ese grupo a otros usuarios también.

Entonces, en su caso, railsse le cambia el nombre para decir myapp_users, luego se crea un nuevo rol de inicio de sesión (usuario) llamado railsy GRANT myapp_users TO rails. Ahora tú un GRANT myapp_users TO meltemi. Tanto la nueva railscuenta como el meltemiusuario ahora tienen los derechos de la railscuenta anterior.

Para un control más detallado, generalmente le aconsejo que evite que los usuarios de inicio de sesión diarios o sus grupos posean las tablas. Darles acceso a través de un NOINHERITgrupo al que deben explícitamente SET GROUP, o mejor, usar un usuario completamente diferente para operaciones privilegiadas como DDL y GRANTs. Desafortunadamente, esto no funciona con Rails, porque a Rails le gusta aplicar migraciones siempre que lo desee y AFAIK no le da la capacidad de especificar un usuario diferente y más privilegiado para ejecutar las migraciones.

— Craig Ringer
fuente

OK, lee la publicación a la que vinculaste; ¡muy útil! Ahora, si estoy entendiendo bien las cosas, ¿creo que es posible que haya querido usar en myapplugar de lo railsanterior? Porque myappposee las tablas (nunca especifiqué eso, la migración debe tener). De todos modos, sería sortA sentido si Retitulé myappa myapp_groupy luego hice un nuevo usuario myapp, que los rieles de aplicación sería utilizar para conectarse a DB. Make myappy el existente meltemi, ambos miembros del myapp_grouprol. Pero, ¿qué sucede cuando ejecuto la próxima migración? ¿No será propiedad de myappvolver a crear el problema nuevamente?

— Meltemi

Debe comprender que PostgreSQL solo tiene roles(desde la versión 8.1). Los términos usery groupse mantienen por razones históricas y de compatibilidad. Básicamente, un "grupo" es un rol sin el privilegio de inicio de sesión. Puede conceder myappa meltemiincluso si myappes sólo otro "usuario". Comience leyendo el manual aquí .

— Erwin Brandstetter

Entiendo la separación rolesvs groupsvs usersseparación en Postgres, al menos creo que sí. Lamento usar la terminología incorrecta (y confusa) anterior. Pero todavía no entiendo cómo configurar mi base de datos, por lo que un rol sin inicio de sesión OWNS la base de datos y dos roles de inicio de sesión myappy meltemiambos pueden tener acceso completo. Una de esas funciones myappserá ejecutar migraciones de Rails que, inevitablemente, crearán nuevas tablas que, una vez más, pertenecen a myappun usuario de inicio de sesión. ¿Debo hacerme meltemiun 'miembro' myappy terminar con esto? Pero eso solo parece torpe ... ¿no?

— Meltemi

@Meltemi: Si desea otorgar todos los privilegios que myappposee meltemi, entonces eso sería lo correcto. Si desea meltemiobtener solo un subconjunto de privilegios, no lo haría. Luego, cree un rol grupal para mantener el conjunto de privilegios y otórguele eso meltemi. Probablemente le interesará esta pregunta relacionada con SO . Respondí explicandoDEFAULT PRIVILEGES

— Erwin Brandstetter, el

@Meltemi Sí, como de costumbre, las migraciones de Rails complican la imagen. Rails realmente debería permitirle especificar una cuenta de usuario diferente para ejecutar migraciones. Posiblemente pueda agregar un SET ROLEcomando al comienzo de sus migraciones y un RESET ROLEfinal, pero no confiaría en que Rails ejecute todo correctamente en orden. Erwin tiene razón; en este caso, la mejor solución será que GRANTlos rieles del usuario otorguen la propiedad al otro usuario, utilizando el primer usuario como grupo para el segundo.

— Craig Ringer