Re: Extension Templates S03E11

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> * Dimitri Fontaine (dimitri(at)2ndQuadrant(dot)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