Dans mon blog précédent, nous avons exploré de nouvelles fonctionnalités de réplication logique avec des tables de partition dans PostgreSQL 13. Inutile de dire qu'il existe une multitude de fonctionnalités de ce type dans la version mentionnée qui amélioreront bientôt l'expérience pour DBA et l'application développeurs.
En regardant PostgreSQL 13, j'ai observé une entrée qui a attiré mon attention :
PostgreSQL 13 introduit le concept d'"extension de confiance", qui permet à un superutilisateur de spécifier des extensions qu'un utilisateur peut installer dans sa base de données tant qu'il dispose d'un privilège CREATE.
Revenons en arrière
Nous savons que PostgreSQL a le pouvoir d'extension pour ajouter des plumes à son plafond sans perturber une grande partie de son noyau. En d'autres termes, les extensions améliorent les capacités fonctionnelles de PostgreSQL Server de manière non intrusive.
En fait, de nombreuses organisations tierces ont utilisé le mécanisme des extensions pour générer des ensembles de fonctionnalités incroyables. TimescaleDB est l'une de ces extensions qui modifie en quelque sorte la personnalité de PostgreSQL Server pour le rendre plus adapté à la charge de travail IOT.
Regardons ce qu'il y avait avant PostgreSQL 13 et pourquoi c'était vraiment pénible. Considérez une instance PostgreSQL hébergée contenant deux rôles :
- postgres (le super utilisateur)
- johnsmith (un utilisateur normal)
Et la base de données wooliesdb.
John Smith aimerait ajouter l'extension postgres hstore à wooliedb, puisque son code d'application s'appuie sur cela. Essayons de le faire.
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'erreur indique clairement que l'extension ne peut être créée que par un super utilisateur, c'est-à-dire postgres. Même si des extensions comme hstore n'ont aucun problème de sécurité dans le contexte de son utilisation, seuls les super utilisateurs peuvent créer cette extension sur la base de données.
Et si la base de données appartenait à ou avait été créée par johnsmith - nous pouvons également essayer cela. Dans l'extrait de code suivant, le superutilisateur postgres autorise johnsmith à créer sa propre base de données pour s'amuser :
$ 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 ! Cela ne fait aucune différence. Même si johnsmith est le propriétaire de jsDB, il ne peut toujours pas installer d'extensions simples et pertinentes dans sa base de données.
Mais c'est tout dans le serveur PostgreSQL 12 (et inférieur) ; cela va changer avec la version 13 de PostgreSQL. Au moment de la rédaction de ce blog, la version 13 de PostgreSQL est en phase Beta2 et l'équipe est déjà en train de rédiger une annonce de publication. Je vais essayer les "extensions de confiance" avec les binaires Beta2.
Voici PostgreSQL 13
Attendez-vous à un comportement différent avec le concept d'extensions de confiance (au moins pour les modules contrib ou les extensions pré-packagées). Vérifions le comportement avec PostgreSQL13 pour les mêmes commandes que nous avons faites pour 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.Ce qui revient à peu près au même, c'est-à-dire que Johnsmith ne peut toujours pas créer l'extension. Mais il y a toujours une différence subtile - le HINT qui suggère que le privilège CREATE est manquant. Notre deuxième ensemble de commandes devrait s'en occuper :
$ 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)
Les choses ont vraiment fonctionné cette fois. Le superutilisateur peut autoriser les mêmes privilèges sur la base de données postgres en exécutant la commande suivante :
postgres=# GRANT CREATE ON DATABASE postgres FOR johnsmith;Mais l'extension de confiance ne se limite pas à cela, essayons de créer une autre extension :
jsDB=> create extension file_fdw;
ERROR: permission denied to create extension "file_fdw"
HINT: Must be superuser to create this extension.La différence vient du fait que si hstore est marqué comme fiable, file_fdw n'est PAS marqué comme fiable. C'est marqué où ? C'est dans le fichier de contrôle des extensions.
$ cd /usr/pgsql-13/share/extension
$ grep -l trusted hstore.control file_fdw.control;
hstore.controlEn fait, il existe 24 extensions fiables et 24 extensions moins fiables fournies avec postgreSQL13.
En bref, les super-utilisateurs peuvent renoncer au contrôle de ces extensions de confiance ; et tout utilisateur disposant des autorisations CREATE sur une base de données peut activer des extensions approuvées sans contacter son administrateur de base de données.
Conclusion
En coulisses, le comportement est contrôlé par deux paramètres dans le fichier de contrôle d'extension :
- superutilisateur, dont la valeur par défaut est true
- de confiance, qui est faux par défaut
Une extension ne peut être créée par un non-superutilisateur que si les deux sont vraies. En fait, une extension approuvée est le script d'installation ou de mise à jour exécuté en tant que superutilisateur d'amorçage, et non en tant qu'utilisateur appelant. N'oubliez pas que les extensions peuvent être écrites dans un langage qui lui-même n'est pas fiable - d'où le besoin.
