In mijn vorige blog hebben we de nieuwe mogelijkheden van logische replicatie met partitietabellen in PostgreSQL 13 onderzocht. Onnodig te zeggen dat er een groot aantal van dergelijke functies in de genoemde release zijn die binnenkort de ervaring voor DBA en applicatie zullen verbeteren zowel ontwikkelaars.
Terwijl ik naar PostgreSQL 13 keek, zag ik een invoer die mijn aandacht trok:
PostgreSQL 13 introduceert het concept van een "vertrouwde extensie", waarmee een superuser extensies kan specificeren die een gebruiker in zijn database kan installeren zolang hij een CREATE-privilege heeft.
Laten we terugspoelen
We weten dat PostgreSQL extensiekracht heeft om veren aan de dop toe te voegen zonder veel van de kern te verstoren. Met andere woorden, extensies verbeteren de functionele mogelijkheden van PostgreSQL Server op een niet-intrusieve manier.
In feite zijn er veel externe organisaties die het extensiemechanisme hebben gebruikt om geweldige functiesets te genereren. TimescaleDB is zo'n extensie waarbij het de persona van PostgreSQL Server verandert om het geschikter te maken voor IOT-werkbelasting.
Laten we eens kijken wat er vóór PostgreSQL 13 was en waarom het erg vervelend was. Overweeg een gehoste PostgreSQL-instantie met twee rollen:
- postgres (de supergebruiker)
- johnsmith (een normale gebruiker)
En de database Wooliesdb.
John Smith wil de postgres-extensie hstore toevoegen aan wooliedb, omdat zijn applicatiecode daarvan afhankelijk is. Laten we dat proberen.
psql -U johnsmith -d wooliesdb
wooliesdb=>CREATE EXTENSION hstore;
ERROR: permission denied to create extension "hstore"
HINT: Must be superuser to create this extension.De fout geeft duidelijk aan dat de extensie alleen kan worden gemaakt door een supergebruiker, d.w.z. postgres. Hoewel extensies zoals hstore geen veiligheidsrisico's hebben in de context van het gebruik, zijn het nog steeds alleen supergebruikers die deze extensie in de database kunnen maken.
Wat als de database eigendom is van of gemaakt is door johnsmith - we kunnen dat ook proberen. In het volgende fragment staat postgres superuser Johnsmith toe om een geheel nieuwe database te maken om mee te spelen:
$ 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! Het maakt geen verschil. Hoewel Johnsmith de eigenaar is van jsDB, kan hij nog steeds geen relevante, eenvoudige extensies voor zijn database installeren.
Maar dat zit allemaal in PostgreSQL-server 12 (en lager); het gaat veranderen met PostgreSQL-versie 13. Op het moment van schrijven van deze blog - PostgreSQL-versie 13 bevindt zich in de bèta2-fase en het team schrijft al een release-aankondiging. Ik ga "vertrouwde extensies" proberen met Beta2-binaire bestanden.
Hier komt PostgreSQL 13
Verwacht een ander gedrag met het concept van vertrouwde extensies (tenminste voor contrib-modules of voorverpakte extensies). Laten we het gedrag met PostgreSQL13 eens bekijken voor dezelfde commando's als voor 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.Dat is vrijwel hetzelfde, d.w.z. Johnsmith kan de extensie nog steeds niet maken. Maar toch is er een subtiel verschil - de HINT die suggereert dat CREATE-privilege ontbreekt. Onze tweede reeks commando's zou daarvoor moeten zorgen:
$ 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)
Het werkte deze keer echt. Superuser kan dezelfde rechten op postgres db toestaan door het volgende commando uit te voeren:
postgres=# GRANT CREATE ON DATABASE postgres FOR johnsmith;Maar er is meer aan een vertrouwde extensie dan dit, laten we proberen een andere extensie te maken:
jsDB=> create extension file_fdw;
ERROR: permission denied to create extension "file_fdw"
HINT: Must be superuser to create this extension.Het verschil komt voort uit het feit dat terwijl hstore is gemarkeerd als vertrouwd, file_fdw NIET is gemarkeerd als vertrouwd. Waar staat dat aangegeven? Het staat in het controlebestand van de extensies.
$ cd /usr/pgsql-13/share/extension
$ grep -l trusted hstore.control file_fdw.control;
hstore.controlIn feite zijn er 24 vertrouwde en 24 niet zo vertrouwde extensies bij postgreSQL13.
In een notendop, superusers kunnen de controle over dergelijke vertrouwde extensies opgeven; en elke gebruiker met CREATE-machtigingen voor een database kan vertrouwde extensies inschakelen zonder zijn databasebeheerder te benaderen.
Conclusie
Achter de schermen wordt het gedrag bepaald door twee parameters in het extensiecontrolebestand:
- superuser, standaard ingesteld op true
- vertrouwd, standaard ingesteld op false
Een extensie kan alleen worden gemaakt door een niet-supergebruiker als beide waar zijn. Een vertrouwde extensie is in feite dat het installatie- of updatescript wordt uitgevoerd als de bootstrap-supergebruiker, niet als de oproepende gebruiker. Onthoud dat extensies geschreven kunnen zijn in een taal die zelf niet vertrouwd is - vandaar de noodzaak.