Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Stephen Frost <sfrost@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