Tom Lane <tgl@sss.pgh.pa.us> writes:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
>>> Then as soon as we are able to CREATE EXTENSION mystuff; without ever
>>> pre-installing files on the file system as root, then we would like to
>>> be able to do just that even with binary modules.
>
>> I really just don't see this as being either particularly useful nor
>> feasible within a reasonable amount of effort. Shared libraries are
>> really the perview of the OS packaging system.
>
> Yes, exactly. What's more, you're going to face huge push-back from
> vendors who are concerned about security (which is most of them).
Last time I talked with vendors, they were working in the Open Shift
team at Red Hat, and they actually asked me to offer them the ability
you're refusing, to let them enable a better security model.
The way they use cgroups and SELinux means that they want to be able to
load shared binaries from system user places.
> If there were such a feature, it would end up disabled, one way or
> another, in a large fraction of installations. That would make it
> impractical to use anyway for most extension authors. I don't think
> it's good project policy to fragment the user base that way.
That point about fragmentation is a concern I share.
> I'm on board with the notion of an all-in-the-database extension
> mechanism for extensions that consist solely of SQL objects. But
> not for ones that need a .so somewhere.
Thanks for restating your position.
The current patch offers a feature that only works with SQL objects,
it's currently completely useless as soon as there's a .so involved.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support