Rozszerzenia umożliwiające Postgresql bez superużytkownika

Mam serwer PostgreSQL 9.5, na którym mam skrypty automatycznie tworzące role i bazy danych dla użytkowników. W tych bazach danych pomocne byłoby włączenie określonych rozszerzeń (np. Pgcrypto), ale jak rozumiem, aby uruchomić, trzeba być superużytkownikiem CREATE EXTENSION. Czy istnieje sposób włączenia takich rozszerzeń bez ręcznego logowania przy użyciu konta administratora?

postgresql permissions postgresql-extensions

— Beldaz
źródło

Czy próbowałeś je dodać, template1a następnie utworzyć bazę danych użytkowników z template1podobnych CREATE DATABASE foo OWNER=userfoo TEMPLATE=template1?

— Kassandry

@ Kassandry nie pomyślał o tym, ale to dobra myśl. Idealnie chciałbym, aby właściciele mogli dodać rozszerzenie, jeśli chcą, ale nadal jest to możliwa do przyjęcia.

— beldaz

Z dokumentów dotyczących rozszerzeń

superuser (boolean) Jeśli ten parametr jest prawdziwy (który jest domyślny), tylko superużytkownicy mogą utworzyć rozszerzenie lub zaktualizować je do nowej wersji. Jeśli ma wartość false, wymagane są tylko uprawnienia wymagane do wykonania poleceń w skrypcie instalacyjnym lub aktualizacyjnym.

Wartość nie jest ustawiona pgcrypto.control, więc domyślnie jest ustawiona na true, co wymaga SuperUser.

Oznacza to, że nie możesz CREATE EXTENSIONjako zwykły właściciel bazy danych, pomimo tego, w co wierzą ci dokumenty z instrukcji CREATE EXTENSION .

Starałem się to ustawić falsei bez radości. C to niezaufany język, a dostaniesz

BŁĄD: odmowa dostępu dla języka c

Z dokumentacji na pg_language

Tylko superużytkownicy mogą tworzyć funkcje w niezaufanych językach.

... oczywiście możesz czaufać UPDATE pg_language set lanpltrusted = true where lanname = 'c';jako superużytkownik. Wtedy CREATE EXTENSION pgcryptobędzie działał dobrze jako nieurządzający. Ale to brzmi źle, jeśli musisz się martwić, że użytkownicy załadują źródło do katalogu rozszerzenia, a następnie zainstalują go w bazie danych. To znaczy, nie posunąłbym się tak daleko. Znalazłbym inny sposób na skórowanie tego kota.

— Evan Carroll
źródło

Dzięki Evan, to jest tak dokładna odpowiedź, o jaką mógłbym prosić. Prawdopodobnie zdecyduję się na propozycję @ Kassandry'ego, aby obejść ten problem. Zastanawiałem się również nad zapakowaniem opcji UTWÓRZ ROZSZERZENIE w procedurze przechowywanej, ale nie mogłem znaleźć drogi do tego, aby ta praca działała w tej samej bazie danych bez szczęsliwego uwierzytelniania dblink.

— beldaz

Po co zatem nie mieć żadnej opcji, pg_dumpaby zapobiec dumpingowi oświadczeń dotyczących rozszerzeń? Obecnie muszę użyć zewnętrznych narzędzi do przetwarzania tekstu, aby usunąć te instrukcje z SQL zrzuconego przez pg_dump.

— Claudix,

@Evan Carroll: czy można ustawić superużytkownika na false za pomocą psql cli? Mam instancję na amazon aws rds i nie mam dostępu do pgcrypto.control.

— ribamar

@ribamar nie, ponieważ oznaczałoby to, że każdy podłączony do bazy danych mógłby wykonać dosłowne wykonanie dowolnego kodu jako postmaster db db. to byłby okropny pomysł.

— Evan Carroll

nie kto, superużytkownik. Rozumiem, że w ten sposób odróżniasz super system operacyjny od superużytkownika dbms, chociaż gdybym podejmował taką decyzję, zdecydowałbym się ulepszyć narzędzie, a jeśli naprawdę potrzebowałbym stworzyć kolejnego, potężniejszego użytkownika, zaimplementowałbym to wewnątrz narzędzia.

— ribamar