PostgreSQL: autorizzazione negata per la relazione


14

Sono un po 'confuso sull'impostazione delle autorizzazioni in PostgreSQL.

Ho questi ruoli:

                             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}

e database:

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

l'utente myappnon ha problemi a interrogare il myapp_productiondatabase aggiungendo ed eliminando i record. Mi piacerebbe meltemianche essere in grado di interrogare lo stesso database. Quindi, ho creato un ruolo railsproprietario del database e creato sia membri meltemiche myappmembri rails. Ma ricevo ancora permission denied for relationerrori. Meltemipuò visualizzare lo schema ma non può interrogare il DB.

Ho appena notato (con \dtcomando) che myappè il proprietario dei tavoli:

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

Le tabelle sono state create tramite un ORM (migrazioni ActiveRecord di Rails).

So che l'autorizzazione è molto diversa in PostgreSQL (al contrario di MySQL e altri che ho usato). Come devo configurare il mio database in modo che diversi utenti possano accedervi. Alcuni dovrebbero essere in grado di CRUD, ma altri potrebbero solo leggere, ecc ...

Grazie per qualsiasi aiuto. Siamo spiacenti, so che questa è una domanda molto semplice, ma non sono stato in grado di trovare la risposta da solo.

Risposte:


4

Ho appena scritto di questo nella mia risposta a concessione dei diritti sul database postgresql a un altro utente su ServerFault.

Fondamentalmente, la soluzione migliore quando si dispone di un singolo utente e si desidera concedere agli altri utenti gli stessi diritti è quella di trasformare quell'utente in un gruppo, creare un nuovo utente con lo stesso nome di quello originale che è membro del gruppo e concedere quel gruppo anche ad altri utenti.

Quindi, nel tuo caso, railsviene rinominato per dire myapp_users, quindi crei un nuovo ruolo di accesso (utente) chiamato railse GRANT myapp_users TO rails. Ora tu un GRANT myapp_users TO meltemi. Sia il nuovo railsaccount che l' meltemiutente hanno ora i diritti del vecchio railsaccount.

Per un controllo più accurato, di solito consiglio di evitare di assegnare agli utenti di accesso giornalieri o ai loro gruppi la proprietà dei tavoli. Concedere loro l'accesso tramite un NOINHERITgruppo a cui devono esplicitamente SET GROUPo meglio utilizzare un utente completamente diverso per operazioni privilegiate come DDL e GRANTs. Sfortunatamente questo non funziona con Rails, perché a Rails piace applicare le migrazioni ogni volta che lo si sente e AFAIK non ti dà la possibilità di specificare un utente diverso e con più privilegi per eseguire le migrazioni.


OK, leggi il post a cui ti sei collegato; molto utile! Ora, se sto capendo le cose nel modo giusto, penso che potresti aver intenzione di usare myappinvece di railssopra? Perché myapppossiede le tabelle (non l'ho mai specificato, la migrazione deve avere). In ogni caso, sarebbe sorta senso se ho rinominato myappper myapp_groupe poi ha fatto un nuovo utente myapp, che l'applicazione Rails avrebbe utilizzato per la connessione al DB. Make myappe l'esistente meltemi, entrambi i membri del myapp_groupruolo. Ma cosa succede quando eseguo la prossima migrazione. non sarà di proprietà myappricreando nuovamente il problema?!?
Meltemi,

1
Devi capire che PostgreSQL ha solo roles(dalla versione 8.1). I termini usere groupsono conservati per ragioni storiche e compatibilità. Fondamentalmente un "gruppo" è un ruolo senza il privilegio di accesso. È possibile concedere myappa meltemianche se myappè solo un altro "user". Inizia leggendo il manuale qui .
Erwin Brandstetter,

Capisco la separazione rolesvs groupsvs usersin Postgres, almeno penso di sì. Ci dispiace usare la terminologia sbagliata (e confusa) sopra. Ma ancora non capisco come impostare il mio database, quindi un ruolo senza accesso PROPRIETÀ del database e due ruoli di accesso myapped meltemientrambi possono avere pieno accesso. Uno di questi ruoli myappeseguirà le migrazioni di Rails che, inevitabilmente?, Creeranno nuove tabelle che sono, ancora una volta, di proprietà di myappun utente di accesso. Devo solo fare meltemiun 'membro' myappe averne finito? Ma questo sembra proprio kludgy ... no?!?
Meltemi,

1
@Meltemi: se vuoi concedere tutti i privilegi che myappdetengono meltemi, allora sarebbe la cosa giusta da fare. Se vuoi meltemiottenere solo un sottoinsieme di privilegi, non lo farebbe. Quindi creare un ruolo di gruppo per contenere l'insieme di privilegi e concederlo a meltemi. Molto probabilmente sarai interessato a questa domanda correlata su SO . Ho risposto spiegandoDEFAULT PRIVILEGES
Erwin Brandstetter il

@Meltemi Sì, come al solito le migrazioni di Rails complicano il quadro. Rails dovrebbe davvero permetterti di specificare un account utente diverso per eseguire le migrazioni come. Puoi eventualmente aggiungere un SET ROLEcomando all'inizio delle migrazioni e RESET ROLEfino alla fine, ma non mi fiderei che Rails esegua tutto in ordine. Erwin ha ragione; in questo caso, la soluzione migliore sarà che GRANTle rotaie dell'utente diano la proprietà all'altro utente, usando il primo utente come gruppo per il secondo.
Craig Ringer,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.