Come posso creare un utente di sola lettura per i backup in PostgreSQL?


15

È vero che è IMPOSSIBILE creare un utente di backup di sola lettura in PostgreSQL?

Mi è stato consigliato su un canale IRC che semplicemente non puoi avere un utente solo di backup senza privilegi di proprietà. Lo trovo molto strano, quindi voglio assicurarmi che non mi manchi qualcosa.

Di seguito è quello che ho provato, ma non mi dà i risultati che sto cercando. Quando lo faccio pg_dumpsu un determinato tavolo ricevo Permission denied for relation...:

GRANT SELECT ON ALL TABLES IN SCHEMA public TO backup; 
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO backup; 
GRANT SELECT, USAGE ON ALL SEQUENCES IN SCHEMA public TO backup;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, USAGE ON SEQUENCES TO backup;

Qualsiasi aiuto sarebbe molto apprezzato!


Risposte:


9

No, è facile (ora comunque).

  1. Concedere l'autorizzazione di connessione per un nuovo utente

    GRANT CONNECT ON DATABASE mydb TO myReadolyUser;
  2. Concedere le autorizzazioni per tutti gli oggetti di database correnti . Questo è specifico dello schema e dovrai eseguire una copia per ogni schema che desideri che il tuo utente possa utilizzare,

    GRANT SELECT ON ALL TABLES IN SCHEMA mySchema TO myReadonlyUser;

    Dai documenti , ALL TABLESinclude tutto ciò che desideri.

    C'è anche un'opzione per concedere i privilegi su tutti gli oggetti dello stesso tipo all'interno di uno o più schemi. Questa funzionalità è attualmente supportata solo per tabelle, sequenze e funzioni (ma nota che TUTTE LE TABELLE sono considerate includere viste e tabelle esterne.

  3. Quindi ALTER DEFAULT PRIVLEGESconcedere privilegi futuri SELECT per oggetti non ancora creati.

    ALTER DEFAULT PRIVILEGES IN SCHEMA mySchema
    GRANT SELECT ON TABLES TO myReadonlyUser;

Ho notato che durante l'esecuzione ALTER DEFAULT PRIVILEGES ... myReadonlyUser, 2 linee aggiuntive vengono aggiunti alla discarica: ALTER DEFAULT PRIVILEGES FOR ROLE root IN SCHEMA public REVOKE ALL ON TABLES FROM PUBLIC; ALTER DEFAULT PRIVILEGES FOR ROLE root IN SCHEMA public REVOKE ALL ON TABLES FROM root;. Sembra che questo significa che root non sarà in grado di fare nulla su nuovi tavoli. È vero?
dor

Inoltre, se le tabelle utilizzano bigintil vostro utente in sola lettura sarà probabilmente bisogno ancheGRANT SELECT ON ALL SEQUENCES
dthor

6

Il modo semplice e piacevole è quello di creare un superutente con autorizzazione di sola lettura.

  • Accesso psql come postgres o altro superutente.
  • Crea il nuovo ruolo di superutente e impostalo in sola lettura:

    CREATE USER backadm SUPERUSER  password '<PASS>';
    ALTER USER backadm set default_transaction_read_only = on;
    • Sostituire <PASS> con la password scelta.
    • Puoi sostituirlo backadmcon il nome utente scelto. (Ho messo backadmperBackup Administrator ).
    • NON dimenticare le virgolette singole per la password.

È ora possibile utilizzare questo ruolo per il backup.


6
Ewww. Un superutente di cui eseguire il backup? Ha specificamente chiesto di sola lettura. Quell'utente è uno SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITEo ALTER USER backadm set default_transaction_read_only = off;lontano dall'accesso illimitato al database.
Evan Carroll,

Questo utente sarà comunque in grado di eliminare tabelle / schemi / database indipendentemente dal fatto che le transazioni siano di sola lettura.
Igor Mukhin,

4

Nota che il blog a cui fa riferimento la risposta data da @Gyre non funzionerà per la creazione di un utente di sola lettura "applicazione" (ovvero per la creazione di un ruolo di sola lettura per un'applicazione Web da connettere al database) e potrebbe aprire un serio vulnerabilità della sicurezza, poiché è facilmente aggirabile, come spiegato in questa risposta all'elenco postgresql . Per riferimento, dal client sovrascrivendo le impostazioni della sessione:

SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE

Fai riferimento alla presentazione "Gestione dei diritti in postgresql" collegata nella wiki di postgres per un metodo più dettagliato, simile a quello pubblicato nella domanda.


Questa non è davvero una risposta, è una critica alle altre risposte per essere insicure che ho copiato come commento. Ho risposto correttamente a questa domanda ora.
Evan Carroll,

3

Dopo aver testato il backup con la soluzione di Evan Caroll, ho riscontrato questo errore:

ERRORE: autorizzazione negata per la relazione 'tabella'

manca un'altra autorizzazione:

GRANT SELECT ON ALL SEQUENCES IN SCHEMA mySchema TO myReadonlyUser

L'aggiunta di questa autorizzazione mi ha permesso di eseguire il backup con il mio utente di sola lettura.


2

Ho fatto delle ricerche adeguate e sembra che ci sia una soluzione per questo. Mi sono imbattuto in questo post sul blog che spiega perfettamente cosa bisogna fare. Spero che questo aiuti alle persone che stanno cercando la stessa mia risposta. Ovviamente, il ripristino dei backup eseguiti in questo modo è una domanda diversa.


Invece di collegarti semplicemente al post del blog, dovresti aggiungere alcuni dettagli alla tua risposta nel caso in cui il post del blog soffra di link-rot (vedi en.wikipedia.org/wiki/Link_rot )
Max Vernon

L'idea di base dal blogpost è ALTER USER set default_transaction_read_only = on;, che non impedisce all'utente di cambiarlo.
arrossato il

Ewww. Un superutente di cui eseguire il backup? Ha specificamente chiesto di sola lettura. Quell'utente è un SET SESSIONE CARATTERISTICHE COME TRANSAZIONE LEGGI SCRIVI o ALTER USER backadm set default_transaction_read_only = off; lontano dall'accesso illimitato al database.
Evan Carroll,
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.