Re: Feature Request on Extensions - Mailing list pgsql-hackers
From | Dave Page |
---|---|
Subject | Re: Feature Request on Extensions |
Date | |
Msg-id | CA+OCxoxoH43qViez1HM+bz+MuOPPQaJY-ixF9Xpfm3EkAqmj2w@mail.gmail.com Whole thread Raw |
In response to | Re: Feature Request on Extensions (Hannu Krosing <hannu@2ndQuadrant.com>) |
Responses |
Re: Feature Request on Extensions
(Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
|
List | pgsql-hackers |
On Sun, Aug 18, 2013 at 10:34 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote: > 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. The escalation happens because in a normal system-wide installation of PostgreSQL as you'd see on most production systems will have the installation directories and binaries owned by the root user, so if the server or a superuser account on it is compromised, the attacker still can't (easily) modify the PostgreSQL installation to do Bad Things, assuming the sysadmin has disabled untrusted PLs. I can see the use case for the change suggested, but I feel pretty strongly that it should not be allowed in a default configuration, and should be something that can be disabled from outside of postgresql.conf (which of course, can often be modified through PostgreSQL by a superuser - and yes, I realise there is risk there too, but no sense adding to that). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: