Postgresql abilita le estensioni senza superutente

Ho un server PostgreSQL 9.5 sul quale ho script che creano automaticamente ruoli e database per gli utenti. All'interno di questi database sarebbe utile abilitare estensioni specifiche (es. Pgcrypto), ma a quanto ho capito bisogna essere un superutente da eseguire CREATE EXTENSION. Esiste un modo per abilitare tali estensioni senza accedere manualmente con un account superutente?

postgresql permissions postgresql-extensions

— beldaz
fonte

Hai provato ad aggiungerli template1e quindi creare ogni database utente template1come CREATE DATABASE foo OWNER=userfoo TEMPLATE=template1?

— Kassandry,

@Kassandry non ci aveva pensato, ma è una buona idea. Idealmente vorrei che i proprietari potessero aggiungere l'estensione se lo desiderano, ma questa è ancora una possibilità accettabile.

— Beldaz,

Dai documenti sulle estensioni,

superutente (booleano) Se questo parametro è true (che è l'impostazione predefinita), solo i super utenti possono creare l'estensione o aggiornarla a una nuova versione. Se è impostato su false, sono richiesti solo i privilegi richiesti per eseguire i comandi nell'installazione o nello script di aggiornamento.

Il valore non è impostato pgcrypto.control, quindi il valore predefinito è true che richiede un SuperUser.

Ciò significa che non puoi essere CREATE EXTENSIONil solo proprietario del database, nonostante ciò che i documenti su CREATE EXTENSION ti portano a credere.

Ho provato a impostarlo su false, e nessuna gioia. C è un linguaggio non attendibile e otterrai

ERRORE: autorizzazione negata per la lingua c

Dai documenti su pg_language

Solo i superutenti possono creare funzioni in lingue non attendibili.

... ovviamente puoi cfidarti di UPDATE pg_language set lanpltrusted = true where lanname = 'c';come superutente. Quindi CREATE EXTENSION pgcryptofunzionerà bene come non-superutente. Ma sembra una cattiva idea se devi preoccuparti che i tuoi utenti caricino il sorgente nella directory delle estensioni e quindi installino nel database. Vale a dire, non andrei così lontano. Troverei un altro modo per scuoiare questo gatto.

— Evan Carroll
fonte

Grazie Evan, questa è una risposta completa come potrei chiedere. Probabilmente opterò per la proposta di skin-skin di Kassandry per aggirare questo. Ho anche pensato di racchiudere CREATE EXTENSION in una procedura memorizzata, ma non sono riuscito a trovare un percorso per far funzionare questo nello stesso database senza il controllo del livello di autenticazione di dblink.

— Beldaz,

Qual è il punto, quindi, di non avere alcuna opzione pg_dumpper impedirne il dumping delle dichiarazioni relative alle estensioni? Attualmente devo usare strumenti di elaborazione del testo esterni per rimuovere quelle dichiarazioni dall'SQL scaricato da pg_dump.

— Claudix,

@Evan Carroll: è possibile impostare il superutente su false tramite psql cli? Ho un'istanza su amazon aws rds e non ho accesso a pgcrypto.control.

— Ribamar,

@ribamar no perché ciò significherebbe che chiunque sia connesso al database potrebbe eseguire letteralmente l'esecuzione di codice arbitrario come postmaster db. sarebbe un'idea orribile.

— Evan Carroll,

nessuno, il superutente. Capisco che in questo modo si differenzia il sistema operativo super dal superutente dbms, anche se se stessi prendendo una decisione del genere andrei per potenziare lo strumento e se davvero avessi bisogno di creare un altro utente più potente, lo implementerei all'interno dello strumento.

— Ribamar