Tom Lane <t...@sss.pgh.pa.us> writes: > Stephen Frost <sfr...@snowman.net> writes: >> * Dimitri Fontaine (dimi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
