Innanzitutto, è necessario essere in grado di connettersi al database per eseguire query. Questo può essere raggiunto da
REVOKE CONNECT ON DATABASE your_database FROM PUBLIC;
GRANT CONNECT
ON DATABASE database_name
TO user_name;
Il REVOKE
è necessaria perché
La parola chiave PUBLIC indica che i privilegi devono essere concessi a tutti i ruoli, compresi quelli che potrebbero essere creati in seguito. PUBLIC può essere pensato come un gruppo implicitamente definito che include sempre tutti i ruoli. Ogni ruolo particolare avrà la somma di privilegi concessi direttamente ad esso, privilegi concessi a qualsiasi ruolo di cui è attualmente membro e privilegi concessi a PUBLIC.
Se vuoi davvero limitare il tuo utente alle istruzioni DML, allora hai un po 'di più da fare:
REVOKE ALL
ON ALL TABLES IN SCHEMA public
FROM PUBLIC;
GRANT SELECT, INSERT, UPDATE, DELETE
ON ALL TABLES IN SCHEMA public
TO user_name;
Questi presuppongono che avrai un solo schema (che è chiamato "pubblico" per impostazione predefinita).
Come ha sottolineato Jack Douglas, quanto sopra offre solo i privilegi per le tabelle già esistenti . Per ottenere lo stesso per le tabelle future, è necessario definire i privilegi predefiniti :
ALTER DEFAULT PRIVILEGES
FOR ROLE some_role -- Alternatively "FOR USER"
IN SCHEMA public
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO user_name;
Qui, some_role
è un ruolo che crea le tabelle, mentre user_name
è quello che ottiene i privilegi. Definendo questo, devi aver effettuato l'accesso come some_role
o un membro di esso.
E, infine, devi fare lo stesso per le sequenze (grazie a PlaidFan per averlo sottolineato): ecco il USAGE
privilegio di cui hai bisogno.
FOR some_role
stata la parte chiave che mi mancava per farlo funzionare per i miei tavoli creati in seguito. Ma non ho dovuto effettuare l'accesso comesome_role
, ha funzionato anche se ho eseguito la query comepostgres
utente amministratore predefinito .