Postgresql habilita extensiones sin superusuario

Tengo un servidor PostgreSQL 9.5 en el que tengo scripts que crean roles y bases de datos para los usuarios automáticamente. Dentro de estas bases de datos, sería útil habilitar extensiones específicas (por ejemplo, pgcrypto), pero según tengo entendido, uno debe ser un superusuario para ejecutarse CREATE EXTENSION. ¿Hay alguna manera de habilitar tales extensiones sin iniciar sesión manualmente con una cuenta de superusuario?

postgresql permissions postgresql-extensions

— beldaz
fuente

¿Has intentado agregarlos template1y luego crear cada base de datos de usuario de me template1gusta CREATE DATABASE foo OWNER=userfoo TEMPLATE=template1?

— Kassandry

@Kassandry no, no había pensado en eso, pero es un buen pensamiento. Idealmente, me gustaría que los propietarios puedan agregar la extensión si lo desean, pero esta sigue siendo una posibilidad aceptable.

— beldaz

De los documentos sobre Extensiones,

superusuario (booleano) Si este parámetro es verdadero (que es el predeterminado), solo los superusuarios pueden crear la extensión o actualizarla a una nueva versión. Si se establece en falso, solo se requieren los privilegios necesarios para ejecutar los comandos en la secuencia de comandos de instalación o actualización.

El valor no está establecido pgcrypto.control, por lo que su valor predeterminado es verdadero, lo que requiere un Superusuario.

Esto significa que no puede CREATE EXTENSIONser el mero propietario de la base de datos, a pesar de lo que los documentos de CREATE EXTENSION lo llevan a creer.

Traté de configurarlo false, y sin alegría. C es un lenguaje no confiable y obtendrá

ERROR: permiso denegado para lenguaje c

De los documentos en pg_language

Solo los superusuarios pueden crear funciones en idiomas no confiables.

... por supuesto, puedes cconfiar en ti UPDATE pg_language set lanpltrusted = true where lanname = 'c';como superusuario. Entonces CREATE EXTENSION pgcryptofuncionará bien como no superusuario. Pero, eso suena como una mala idea si tiene que preocuparse de que sus usuarios carguen la fuente en su directorio de extensiones y luego la instalen en la base de datos. Es decir, no iría tan lejos. Encontraría otra forma de pelar a este gato.

— Evan Carroll
fuente

Gracias Evan, esa es una respuesta tan completa como podría pedir. Probablemente optaré por la propuesta de desollado de gato de @ Kassandry para solucionar esto. También pensé en envolver CREATE EXTENSION en un procedimiento almacenado, pero no pude encontrar una ruta para hacer que esto funcione en la misma base de datos sin dblink autenticación yuckiness.

— beldaz

¿Cuál es el punto, entonces, de no tener ninguna opción pg_dumppara evitar que descargue declaraciones sobre extensiones? Actualmente tengo que usar herramientas de procesamiento de texto externo para eliminar esas declaraciones del SQL descargado por pg_dump.

— Claudix 01 de

@Evan Carroll: ¿es posible establecer el superusuario en falso a través de psql cli? Tengo una instancia en amazon aws rds y no tengo acceso a pgcrypto.control.

— ribamar

@ribamar no porque eso significaría que cualquier persona conectada a la base de datos podría realizar una ejecución literal de código arbitrario como el administrador de correo db. Esa sería una idea horrible.

— Evan Carroll

nadie, el superusuario. Entiendo que de esta manera usted diferencia el sistema operativo super del superusuario dbms, aunque si tomara esa decisión, optaría por potenciar la herramienta, y si realmente fuera necesario para crear otro usuario más poderoso, lo implementaría dentro de la herramienta.

— ribamar