From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Oliver Charles <ollie(at)ocharles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Configurable location for extension .control files |
Date: | 2013-06-10 14:13:45 |
Message-ID: | 21333.1370873625@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-06-10 14:18:08 | Re: JSON and unicode surrogate pairs |
Previous Message | Dimitri Fontaine | 2013-06-10 14:06:46 | Re: ALTER TABLE ... ALTER CONSTRAINT |