Hi, I had the chance to being at OSCON this year and had a chat with the Open Shift team while there. Thanks for posting your use case!
Tom Lane <t...@sss.pgh.pa.us> writes: > Right offhand, it seems like you have or could grant a developer > superuser/DBA privileges with respect to his own PG instance, so I'm not > actually seeing why you have a problem. What exactly is stopping him > from installing his extension in the normal way? They use the same binary installation for everyone, and an OS packaged one at that. Which means that there's a single `libdir` and `pkglibdir` shared globally on the system. And no individual user has any privileges down there as it's a global OS location. What they want is to be able to run the same binary for every user, yet have a personal `libdir` place where to load extension's .so files from, and point that to a place owned by the initdb bootstrap superuser, different each time. The easiest way for them here would be for this parameter to be a fully dynamic setting, second best an initdb option, IIUC. The way they make that secure in their model is by using modern approaches to security, or at least modern enough that we don't get to envision those offerings when we usually talk about the idea of allowing the backend to load non-root-owned binary modules: SElinux and CGroups. 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
