Utilizzando PostgreSQL 9.0, ho un ruolo di gruppo chiamato "staff" e vorrei concedere tutti (o alcuni) privilegi a questo ruolo sulle tabelle di un particolare schema. Nessuno dei seguenti lavori

GRANT ALL ON SCHEMA foo TO staff;
GRANT ALL ON DATABASE mydb TO staff;

I membri dello "staff" non sono ancora in grado di SELEZIONARE o AGGIORNARE sulle singole tabelle nello schema "pippo" o (nel caso del secondo comando) su qualsiasi tabella del database a meno che non conceda tutto su quella specifica tabella.

Cosa posso fare per rendere più facile la mia vita e quella dei miei utenti?

Aggiornamento: risolto con l'aiuto di una domanda simile su serverfault.com .

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO staff;

Hai trovato l'abbreviazione per impostare i privilegi per tutte le tabelle esistenti nello schema dato. Il manuale chiarisce :

(ma si noti che ALL TABLESè considerato includere viste e tabelle esterne ).

Grassetto mio. serialle colonne sono implementate con nextval()su una sequenza come colonna predefinita e, citando il manuale :

Per le sequenze, questo privilegio consente l'uso delle funzioni currvale nextval.

Quindi, se ci sono serialcolonne, ti consigliamo di concedere USAGE(o ALL PRIVILEGES) anche sulle sequenze

GRANT USAGE ON ALL SEQUENCES IN SCHEMA foo TO mygrp;

Nota: le colonne Identity in Postgres 10 o versioni successive utilizzano sequenze implicite che non richiedono privilegi aggiuntivi. (Prendi in considerazione l'aggiornamentoserial colonne.)

E il nuovo oggetti?

Sarai anche interessato a DEFAULT PRIVILEGESutenti o schemi :

ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT ALL PRIVILEGES ON TABLES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT USAGE          ON SEQUENCES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo REVOKE ...;

Questo imposta automaticamente i privilegi per gli oggetti creati in futuro, ma non per gli oggetti preesistenti.

I privilegi predefiniti vengono applicati solo agli oggetti creati dall'utente di destinazione ( FOR ROLE my_creating_role). Se quella clausola viene omessa, il valore predefinito è l'utente corrente in esecuzione ALTER DEFAULT PRIVILEGES. Per essere espliciti:

ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo GRANT ...;
ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo REVOKE ...;

Notare inoltre che tutte le versioni di pgAdmin III hanno un bug sottile e visualizzano i privilegi predefiniti nel riquadro SQL, anche se non si applicano al ruolo corrente. Assicurati di regolare FOR ROLEmanualmente la clausola quando copi lo script SQL.

La mia risposta è simile a questa su ServerFault.com .

Essere conservatore

Se vuoi essere più conservatore che concedere "tutti i privilegi", potresti provare qualcosa di più simile a questi.

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO some_user_;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO some_user_;

L'impiego di public li si riferisce al nome dello schema predefinito creato per ogni nuovo database / catalogo. Sostituisci con il tuo nome se hai creato uno schema.

Accesso allo schema

Per accedere a uno schema, per qualsiasi azione, l'utente deve disporre dei diritti di "utilizzo". Prima che un utente possa selezionare, inserire, aggiornare o eliminare, a un utente deve essere concesso "l'utilizzo" di uno schema.

Non noterai questo requisito la prima volta che utilizzi Postgres. Per impostazione predefinita, ogni database ha un primo schema denominato public. E a ogni utente per impostazione predefinita sono stati concessi automaticamente i diritti di "utilizzo" per quel particolare schema. Quando si aggiunge uno schema aggiuntivo, è necessario concedere esplicitamente i diritti di utilizzo.

GRANT USAGE ON SCHEMA some_schema_ TO some_user_ ;

Estratto dal documento Postgres :

Per gli schemi, consente l'accesso agli oggetti contenuti nello schema specificato (supponendo che siano soddisfatti anche i requisiti di privilegio degli oggetti). In sostanza, ciò consente al beneficiario di "cercare" oggetti all'interno dello schema. Senza questa autorizzazione, è ancora possibile vedere i nomi degli oggetti, ad esempio interrogando le tabelle di sistema. Inoltre, dopo aver revocato questa autorizzazione, i backend esistenti potrebbero contenere istruzioni che hanno precedentemente eseguito questa ricerca, quindi questo non è un modo completamente sicuro per impedire l'accesso agli oggetti.

Per ulteriori discussioni, vedere la domanda, cosa fa esattamente l'uso della sovvenzione su SCHEMA? . Presta particolare attenzione alla risposta dell'esperto di Postgres Craig Ringer .

Oggetti esistenti contro futuro

Questi comandi hanno effetto solo sugli oggetti esistenti. Le tabelle e simili che creerai in futuro ottengono privilegi predefiniti fino a quando non riesci a eseguire quelle righe sopra. Vedere l' altra risposta di Erwin Brandstetter per modificare le impostazioni predefinite influendo in tal modo sugli oggetti futuri.