Postgresql habilitando extensões sem superusuário

Eu tenho um servidor PostgreSQL 9.5 no qual tenho scripts que criam funções e bancos de dados para usuários automaticamente. Dentro desses bancos de dados, seria útil habilitar extensões específicas (por exemplo, pgcrypto), mas, pelo que entendi, é preciso ser um superusuário para executar CREATE EXTENSION. Existe uma maneira de habilitar essas extensões sem fazer login manualmente com uma conta de superusuário?

postgresql permissions postgresql-extensions

— Beldaz
fonte

Você já tentou adicioná-los ao template1e, em seguida, a criação de cada banco de dados de usuário de template1como CREATE DATABASE foo OWNER=userfoo TEMPLATE=template1?

— Kassandry

@ Kassandry não tinha pensado nisso, mas é um bom pensamento. Idealmente, eu gostaria que os proprietários pudessem adicionar a extensão, se assim o desejassem, mas essa ainda é uma possibilidade aceitável.

— precisa saber é

Nos documentos sobre extensões,

superusuário (booleano) Se esse parâmetro for verdadeiro (que é o padrão), apenas os superusuários poderão criar a extensão ou atualizá-la para uma nova versão. Se estiver definido como false, apenas os privilégios necessários para executar os comandos no script de instalação ou atualização serão necessários.

O valor não está definido pgcrypto.control, portanto, é padronizado como true, o que requer um superusuário.

Isso significa que você não pode ser CREATE EXTENSIONo mero proprietário do banco de dados, apesar do que os documentos sobre CREATE EXTENSION levam você a acreditar.

Eu tentei arduamente configurá-lo false, e sem alegria. C é uma linguagem não confiável e você terá

ERRO: permissão negada para o idioma c

Dos documentos em pg_language

Somente superusuários podem criar funções em idiomas não confiáveis.

... é claro que você pode cconfiar UPDATE pg_language set lanpltrusted = true where lanname = 'c';como superusuário. Então CREATE EXTENSION pgcryptofuncionará bem como um não superusuário. Mas isso parece uma péssima idéia se você precisar se preocupar com o upload de código-fonte dos usuários para o diretório de extensões e a instalação no banco de dados. Ou seja, eu não iria tão longe. Eu encontraria outra maneira de esfolar esse gato.

— Evan Carroll
fonte

Obrigado Evan, é uma resposta tão completa quanto eu poderia pedir. Provavelmente vou optar pela proposta de pele de gato de @ Kassandry para contornar isso. Também pensei em agrupar a CREATE EXTENSION em um procedimento armazenado, mas não consegui encontrar uma rota para fazer esse trabalho no mesmo banco de dados sem a dinkink autenticação yuckiness.

— precisa saber é

Qual é o objetivo, então, de não ter nenhuma opção pg_dumppara impedir que ele despeje declarações sobre extensões? Atualmente, tenho que usar ferramentas externas de processamento de texto para remover essas instruções do SQL despejado por pg_dump.

— Claudix 01/07/19

@Evan Carroll: é possível definir o superusuário como false via psql cli? Eu tenho uma instância no amazon aws rds e não tenho acesso ao pgcrypto.control.

— Ribamar #

@ribamar não, porque isso significaria que qualquer pessoa conectada ao banco de dados poderia executar literalmente a execução arbitrária de código como o postmaster do db. isso seria uma ideia horrível.

— Evan Carroll

ninguém, o superusuário. Entendo que desta maneira você diferencia o super sistema operacional do super usuário dbms, embora, se eu estivesse tomando essa decisão, eu usasse a ferramenta e, se realmente fosse necessário criar outro usuário mais poderoso, eu o implementaria dentro da ferramenta.

— Ribamar