Autorizzazione negata per la relazione <table>

Ho eseguito il seguente SQL in psql:

CREATE USER bspu LOGIN;

CREATE DATABASE bsp OWNER bspu;

GRANT ALL PRIVILEGES ON DATABASE bsp TO bspu;

\c bsp

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  client_id VARCHAR(20) NOT NULL,
  api_key VARCHAR(100) NOT NULL,
  api_secret VARCHAR(100) NOT NULL,
  auth_token VARCHAR(128) NOT NULL
);

Quando accedo come bspu, e provo a interrogare la userstabella, ottengo l'errore:

permission denied for relation users

Ho provato a correre:

ALTER DEFAULT PRIVILEGES GRANT ALL ON TABLES TO bspu;

Ma non aiuta. Che cosa sto facendo di sbagliato? Perché il proprietario del database NON dispone delle autorizzazioni per interrogare il proprio database?

EDIT: bspuper ora ho effettuato l'aggiornamento a superutente, quindi posso continuare a lavorare. Ogni ulteriore consiglio è apprezzato.

postgresql permissions

— se __name__ è Nessuno
fonte

Cosa \dt "users"mostra l'output di ?

— bma

@bma è elencato solo il mio acc principale.

— se __name__ è Nessuno

Hai eseguito i comandi iniziali come utente? Cosa ottieni SELECT session_user, current_usernella parte superiore della tua sceneggiatura? E qual è la tua versione di Postgres?

— Erwin Brandstetter,

Se questi fossero gli esatti comandi che hai eseguito, allora sei ancora connesso con il tuo 'acc principale'. Quindi viene giù quali privilegi hai . Altrimenti, vedi l'eccellente risposta di Erwin. (Permettetemi di ammettere che mi sembra stupido che questo messaggio di errore non dica quale ruolo non ha l'autorizzazione. Ad esempio, quando si esegue una catena di funzioni con SECURITY DEFINER, diventa abbastanza veloce confondere chi è chi.)

— dezso

Risposte:

DEFAULT PRIVILEGESnon non modificare le autorizzazioni per esistenti oggetti. Sono i privilegi predefiniti per gli oggetti appena creati e solo per il ruolo particolare a cui appartengono. Se non si definisce il ruolo durante l'esecuzione ALTER DEFAULT PRIVILEGES, per impostazione predefinita assume il ruolo corrente (quando si esegue l' ALTER DEFAULT PRIVILEGESistruzione.

Inoltre, poiché stai utilizzando una serialcolonna, che crea un SEQUENCE, ti consigliamo di impostare anche i privilegi predefiniti per le sequenze.

Esegui questo sull'utente con cui crei oggetti, prima di eseguire il CREATEcomando:

ALTER DEFAULT PRIVILEGES [ FOR ROLE my_create_role] GRANT ALL ON TABLES TO bspu;
ALTER DEFAULT PRIVILEGES [ FOR ROLE my_create_role] GRANT ALL ON SEQUENCES TO bspu;

Se dovresti usare pgAdmin, un avvertimento. È presente un bug nell'attuale versione 1.20 (o precedente) nella visualizzazione dello script SQL con reverse engineering per DEFAULT PRIVILEGES. Il display ignora l'utente proprietario ed è quindi errato in determinate situazioni. Ho segnalato il bug, la questione è in sospeso .

Per gli oggetti esistenti potresti anche essere interessato a questo modulo "batch" del GRANTcomando :

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO bspu;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO bspu;

Più sotto questa domanda correlata su SO:

Concedi tutto su uno schema specifico nel db a un ruolo di gruppo in PostgreSQL

— Erwin Brandstetter
fonte

Il bug menzionato persiste ancora in pgAdmin4, vedi redmine.postgresql.org/issues/4685 , che è stato contrassegnato come duplicato di redmine.postgresql.org/issues/4256

— dpprdan

-1

This is working for me after some research. psql (9.6.12)

-- login to postgres database server as postgres user.
ssh <user>>@hostname.<domain>>.com
sudo su postgres
id
psql
postgres=# create user sentry_read with login password 'sentry_read';
postgres=# du+
postgres=# \l+
-- **very important: make sure we should connect required database before we grant to user.**
postgres=# \c sentry
postgres=# \dt
sentry=# \dp SENTRY_VERSION
sentry=# select * from "SENTRY_VERSION";
sentry=# GRANT SELECT ON ALL TABLES IN SCHEMA public TO sentry_read;
postgres=# \q

[user@hostname ~]$ psql -U sentry_read -d sentry -h hostname.<domain>>.com -W
sentry=> select * from "SENTRY_VERSION";

— Srinu Mareti
fonte