On 2013-06-10 10:13:45 -0400, Tom Lane wrote:
> 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.
Why does it need to be a non-distribution postgres? A customer
needing to develop a postgres extensions is a fairly frequent thing, but
often enough they are still happy to use a distribution postgres.
> 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.
I fail to see the logic here. We do allow LOAD with arbitrary paths. We
do allow untrusted languages. We do allow specifying arbitrary paths in
'C' CREATE FUNCTION statements. ...
Sure, all of that requires superuser, but so does anything in an
extension that can cause an .so to be loaded?
Why are extensions different?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
