Dimitri Fontaine <dimi...@2ndquadrant.fr> writes: > Stephen Frost <sfr...@snowman.net> writes: >> That's only accurate if the new mechanism supports .so's, which seems >> unlikely to be the case.
> Really? Yes, really. > 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. > If you don't like what I'm building because it's not solving the problem > you want to solve⦠well don't use what I'm building, right? What worries me is that time and effort will go into this instead of something that would be universally acceptable/useful. I grant that there are some installations whose security policies are weak enough that they could use what you want to build. But I'm not sure how many there are, and I'm worried about market fragmentation if we need to have more than one distribution mechanism. Of course, we're already talking about two distribution infrastructures (one for packages including .so's, and one for those without). I see no way around that unless we settle for the status quo. But what you're suggesting will end up with three distribution infrastructures, with duplicative methods for packages including .so's depending on whether they're destined for security-conscious or less-security-conscious platforms. I don't want to end up with that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers