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 restored. 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
