On 17 December 2013 17:54, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> So now, you don't need anymore to have file system write privileges into
>> a central place owned by root, it can be anywhere else,
> Modern OSes have security checks that can prevent loading libraries from
> random places. This is widely seen as not merely a good thing, but
> security-critical for network-exposed daemons. Of which we are one.
> I keep telling you this, and it keeps not sinking in. One more time: any
> feature that does what you want will be dead on arrival so far as vendors
> like Red Hat are concerned. I don't care how creatively you argue for it,
> they will refuse to ship it (or at least refuse to disable the SELinux
> policy that prevents it). Period. Please stop wasting my time with
> suggestions otherwise, because it won't happen.
> So what we have left to discuss is whether we want to develop, and base a
> community extension-distribution infrastructure on, a mechanism that some
> popular vendors will actively block. I'm inclined to think it's a bad
> idea, but I just work here.
Yes, there is a strong argument against enabling Postgres
out-of-the-box to allow loading of .so files from random places and
bypassing distro security procedures.
But that argument doesn't apply to all types of extension. For example, data.
In any case, right now, its easy to load an FDW and then do an INSERT
SELECT from a foreign server into a text column. There are no
restrictions on URLs to access foreign servers. Then write a *trusted*
PL/pgSQL procedure to execute the contents of the text column to do
whatever. All you need is the Postgres foreign data wrapper loaded, an
insecure URL and a route to it.
I don't see a material difference between that route and the new one
proposed. The only difference is really that the new route would be
blessed as being the officially recommended way to import objects
without needing a file, and to allow them to be backed up and
So perhaps all we need is a module that once loaded allows other
things to be loaded. (Red Hat etc can then ban that as they see fit.)
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: