On 08/18/2013 10:20 PM, Dimitri Fontaine wrote:
> 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.
Even without SELinux I can not immediately see the security weakening
when you allow the backend to load .so-s from directories which are
owned by the user both the client and the backend runs as.
so say there is system user 'bob' who has his own instance of database
initdb-ed in /home/bob/pgsql and running as user bob, with bob also being
the "main" superuser for the cluster.
User bob can then CREATE EXTENSION which loads .so-s from
/home/bob/libpgsql
and if a more restricted user is needed for web client database access
then bob can do CREATE USER lesserbob; for this.
I think this is something that should be secure even with standard
non-SELinux install.
Feel free to point out where a security escalation is possible with such
a use case.
Regards,
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
