Nel mio blog precedente, abbiamo esplorato le nuove funzionalità della replica logica con le tabelle di partizione in PostgreSQL 13. Inutile dire che ci sono molte funzionalità di questo tipo nella versione menzionata che presto miglioreranno l'esperienza per DBA e applicazioni sviluppatori allo stesso modo.
Guardando PostgreSQL 13, ho notato una voce che ha attirato la mia attenzione:
PostgreSQL 13 introduce il concetto di "estensione attendibile", che consente a un superutente di specificare le estensioni che un utente può installare nel proprio database purché disponga del privilegio CREATE.
Riavvolgiamo
Sappiamo che PostgreSQL ha un potere di estensione per aggiungere piume al suo cappuccio senza disturbare gran parte del suo core. In altre parole, le estensioni migliorano le capacità funzionali di PostgreSQL Server in modo non intrusivo.
In effetti, ci sono molte organizzazioni di terze parti che hanno utilizzato il meccanismo delle estensioni per generare incredibili set di funzionalità. TimescaleDB è una di queste estensioni in cui cambia la persona di PostgreSQL Server per renderlo più adatto al carico di lavoro IOT.
Diamo un'occhiata a cosa c'era prima di PostgreSQL 13 e perché è stato un vero problema. Considera un'istanza PostgreSQL ospitata contenente due ruoli:
- postgres (il super utente)
- johnsmith (un utente normale)
E il database wooliesdb.
John Smith vorrebbe aggiungere l'estensione postgres hstore a wooliedb, poiché il suo codice dell'applicazione si basa su questo. Proviamo a farlo.
psql -U johnsmith -d wooliesdb
wooliesdb=>CREATE EXTENSION hstore;
ERROR: permission denied to create extension "hstore"
HINT: Must be superuser to create this extension.
L'errore indica chiaramente che l'estensione può essere creata solo da un super utente, ad esempio postgres. Anche se estensioni come hstore non hanno alcun problema di sicurezza nel contesto del suo utilizzo, sono comunque solo i super utenti che possono creare questa estensione sul database.
E se il database fosse di proprietà o creato da johnsmith? Possiamo provare anche questo. Nello snippet seguente, il superutente postgres consente a johnsmith di creare un database completamente nuovo per giocare:
$ psql -U postgres
postgres=# ALTER ROLE johnsmith CREATEDB;
postgres=# \q
$ psql -U johnsmith -d wooliesdb
wooliesdb=>CREATE DATABASE jsDB;
wooliesdb=>\c jsDB;
You are now connected to database "jsDB" as user "johnsmith".
jsDB=>CREATE EXTENSION hstore;
ERROR: permission denied to create extension "hstore"
HINT: Must be superuser to create this extension.
Ah! Non fa alcuna differenza. Anche se johnsmith è il proprietario di jsDB, non può ancora installare estensioni pertinenti e semplici nel suo database.
Ma questo è tutto nel server PostgreSQL 12 (e sotto); cambierà con PostgreSQL versione 13. Al momento della stesura di questo blog - PostgreSQL versione 13 è in fase Beta2 e il team sta già scrivendo un annuncio di rilascio. Proverò le "estensioni attendibili" con i binari Beta2.
Ecco che arriva PostgreSQL 13
Prevedi un comportamento diverso con il concetto di estensioni attendibili (almeno per i moduli contrib o le estensioni preconfezionate). Controlliamo il comportamento con PostgreSQL13 per gli stessi comandi che abbiamo fatto per PostgreSQL12.
$ psql -U johnsmith -d wooliesdb
wooliesdb=>CREATE EXTENSION hstore;
ERROR: permission denied to create extension "hstore"
HINT: Must have CREATE privilege on current database to create this extension.
Che è più o meno lo stesso, ovvero johnsmith non riesce ancora a creare l'estensione. Ma c'è ancora una sottile differenza:il SUGGERIMENTO che suggerisce che manca il privilegio CREATE. La nostra seconda serie di comandi dovrebbe occuparsene:
$ psql -U postgres
postgres=# ALTER ROLE johnsmith CREATEDB;
postgres=# \q
$ psql -U johnsmith -d wooliesdb
wooliesdb=>CREATE DATABASE jsDB;
wooliesdb=>\c jsDB;
You are now connected to database "jsDB" as user "johnsmith".
jsDB=>CREATE EXTENSION hstore;
jsDB=>SELECT extname from pg_extension;
extname
---------
plpgsql
hstore
(2 rows)
Le cose hanno funzionato davvero questa volta. Il superutente può concedere gli stessi privilegi su postgres db eseguendo il comando seguente:
postgres=# GRANT CREATE ON DATABASE postgres FOR johnsmith;
Ma c'è di più nell'estensione attendibile, proviamo a creare un'altra estensione:
jsDB=> create extension file_fdw;
ERROR: permission denied to create extension "file_fdw"
HINT: Must be superuser to create this extension.
La differenza deriva dal fatto che mentre hstore è contrassegnato come attendibile, file_fdw NON è contrassegnato come attendibile. Dove è segnato? È nel file di controllo delle estensioni.
$ cd /usr/pgsql-13/share/extension
$ grep -l trusted hstore.control file_fdw.control;
hstore.control
In effetti, ci sono 24 estensioni attendibili e 24 non così attendibili fornite con postgreSQL13.
In poche parole, i superutenti possono rinunciare al controllo su tali estensioni affidabili; e qualsiasi utente con le autorizzazioni CREATE su un database può abilitare estensioni attendibili senza rivolgersi al suo amministratore del database.
Conclusione
Dietro le quinte, il comportamento è controllato da due parametri nel file di controllo dell'estensione:
- superutente, che per impostazione predefinita è true
- fidato, che per impostazione predefinita è false
Un'estensione può essere creata da un non superutente solo se entrambi sono veri. In effetti, un'estensione attendibile è che lo script di installazione o aggiornamento viene eseguito come superutente bootstrap, non come utente chiamante. Ricorda che le estensioni potrebbero essere scritte in un linguaggio che di per sé non è affidabile, da qui la necessità.