Re: Configurable location for extension .control files - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Configurable location for extension .control files
Date
Msg-id 21333.1370873625@sss.pgh.pa.us
Whole thread Raw
In response to Re: Configurable location for extension .control files  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Configurable location for extension .control files
List 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 by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: ALTER TABLE ... ALTER CONSTRAINT
Next
From: Tom Lane
Date:
Subject: Re: JSON and unicode surrogate pairs