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 <tgl@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
