Re: Configurable location for extension .control files

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Configurable location for extension .control files
Дата
Msg-id 21333.1370873625@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Configurable location for extension .control files  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Configurable location for extension .control files  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> For sites where they don't have in-house system packagers, it would be
> very welcome to be able to setup PostgreSQL in a way that allows it to
> LOAD the extension's binary code (.so, .dll, .dylib) from a non-root
> owned place even if you installed it from official packages.

> Of course, it wouldn't be activated by default and frowned upon in the
> docs for conservative production environments. The use case still seems
> valid to me, and would nicely complete the Extension Templates facility
> given the right tooling.

> Can I prepare a patch allowing PostgreSQL to load extension control
> files and modules from a non-default place in the file-system? Please?

I don't see the need for this.  The sort of situation you're describing
probably has PG installed at a non-default install --prefix anyway, and
thus the "standard" extension directory is already not root-owned.

More generally, it seems pretty insane to me to want to configure a
"trusted" PG installation so that it can load C code from an untrusted
place.  The trust level cannot be any higher than the weakest link.
Thus, I don't see a scenario in which any packager would ship binaries
using such an option, even if it existed.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: ALTER TABLE ... ALTER CONSTRAINT
Следующее
От: Tom Lane
Дата:
Сообщение: Re: JSON and unicode surrogate pairs