Postgresql permettant des extensions sans super-utilisateur

J'ai un serveur PostgreSQL 9.5 sur lequel j'ai des scripts qui créent automatiquement des rôles et des bases de données pour les utilisateurs. Dans ces bases de données, il serait utile d'activer des extensions spécifiques (par exemple pgcrypto), mais si je comprends bien, il faut être un superutilisateur pour fonctionner CREATE EXTENSION. Existe-t-il un moyen d'activer de telles extensions sans vous connecter manuellement avec un compte superutilisateur?

postgresql permissions postgresql-extensions

— beldaz
source

Avez-vous essayé de les ajouter à template1, puis de créer chaque base de données d'utilisateurs à partir de template1comme CREATE DATABASE foo OWNER=userfoo TEMPLATE=template1?

— Kassandry

@Kassandry n'y avait pas pensé, mais c'est une bonne idée. Idéalement, j'aimerais que les propriétaires puissent ajouter l'extension s'ils le souhaitent, mais c'est toujours une possibilité acceptable.

— beldaz

Depuis la documentation sur les extensions,

superutilisateur (booléen) Si ce paramètre est vrai (qui est la valeur par défaut), seuls les superutilisateurs peuvent créer l'extension ou la mettre à jour vers une nouvelle version. S'il est défini sur false, seuls les privilèges requis pour exécuter les commandes dans le script d'installation ou de mise à jour sont requis.

La valeur n'est pas définie pgcrypto.control, donc sa valeur par défaut est true, ce qui nécessite un SuperUser.

Cela signifie que vous ne pouvez pas en CREATE EXTENSIONtant que simple propriétaire de la base de données, malgré ce que les documents sur CREATE EXTENSION vous font croire.

J'ai essayé de le régler durement false, et pas de joie. C est un langage non fiable et vous obtiendrez

ERREUR: autorisation refusée pour la langue c

Depuis les documents sur pg_language

Seuls les superutilisateurs peuvent créer des fonctions dans des langues non fiables.

... bien sûr, vous pouvez faire cconfiance en UPDATE pg_language set lanpltrusted = true where lanname = 'c';tant que superutilisateur. Ensuite CREATE EXTENSION pgcrypto, fonctionnera bien en tant que non-superutilisateur. Mais cela semble être une mauvaise idée si vous devez vous soucier du téléchargement de la source de vos utilisateurs vers votre répertoire d'extension, puis de son installation dans la base de données. C'est-à-dire que je n'irais pas aussi loin. Je trouverais un autre moyen d'écorcher ce chat.

— Evan Carroll
source

Merci Evan, c'est une réponse aussi complète que je pourrais demander. J'opterai probablement pour la proposition de peau de chat de @ Kassandry pour contourner ce problème. J'ai aussi pensé à encapsuler CREATE EXTENSION dans une procédure stockée, mais je n'ai pas trouvé de chemin pour que cela fonctionne dans la même base de données sans yinkiness d'authentification dblink.

— beldaz

Quel est donc l'intérêt de n'avoir aucune option pg_dumppour l'empêcher de vider les déclarations concernant les extensions? Je dois actuellement utiliser des outils de traitement de texte externes pour supprimer ces instructions du SQL sous-évaluées par pg_dump.

— Claudix

@Evan Carroll: est-il possible de définir le superutilisateur sur false via psql cli? J'ai une instance sur amazon aws rds et je n'ai pas accès à pgcrypto.control.

— ribamar

@ribamar non car cela signifierait que toute personne connectée à la base de données pourrait exécuter littéralement du code arbitraire en tant que postmaster db. ce serait une horrible idée.

— Evan Carroll le

personne, le superutilisateur. Je comprends que de cette façon, vous différenciez le système d'exploitation super du super utilisateur dbms, bien que si je prenais une telle décision, j'irais pour alimenter l'outil, et si vraiment besoin de créer un autre utilisateur plus puissant, je le mettrais en œuvre à l'intérieur de l'outil.

— ribamar