Feature Request on Extensions

From: Steven Citron-Pousty <spousty(at)redhat(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: "shifters(at)redhat(dot)com shifters" <shifters(at)redhat(dot)com>, Matthew Hicks <mhicks(at)redhat(dot)com>, Hirotsugu Asari <hasari(at)redhat(dot)com>, Adam Miller <admiller(at)redhat(dot)com>
Subject: Feature Request on Extensions
Date: 2013-08-17 21:53:13
Message-ID: 341087492.2585530.1376776393038.JavaMail.root@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings all:
I spoke to Josh B and company at OSCON about a feature we really need for PostgreSQL extensions on OpenShift (Red Hat's Platform as a Service).

What we need is the ability for Postgresql to load extensions from a users file space. For example, if, as a developer on a machine, I wanted to load PostGIS into PostgreSQL, I should be able to (either at DB start, Cluster Initiatialization, or from within the psql command line) specify an additional path where PostgreSQL can look for the binaries for extensions. Compile time is not an acceptable solution UNLESS, that compile time parameter can be an environment variable that is present for all users but points to different locations. This feature would be turned on or off at the whole database level.

I know that under a typical server install scenario this would be a bad from a security perspective, but on OpenShift we runs things differently. Let me explain what happens when a developer creates an application on OpenShift:

1) Each developer application on OpenShift is actually a unique user on the Linux machine.
2) That user is locked down very tight using SELinux and CGroups to create a container like environment.
3) We then start up an instance of PostgreSQL server running as that unique user. If there are 30 applications using Postgresql on that node in our OpenShift cluster then there will be 30 instances of Postgresql running on the machine each as a different userid. But the binary they start from is the single binary that is laid down in the OS. Therefore everyone is starting from the same binary and they share all the binaries.
4) The developer does not have permissions to add binaries (or any files) to locations other /home/<uniqueuserid>/app-root/data and a PAM namespaced /tmp. So even while a user could probably download all the pieces necessary to compile an extension they have no way to actually write the binaries for the extension to the correct Postgresql file location.

What this means for OpenShift is that the we have to approve, package, and maintain any extension that a user wants to use. But we don't want to have that relationship between the developer and their Postgresql extensions. Given our security model we don't care what extension they want to run (as long as they don't violate the TOS).

So what we really need is the ability to tell Postgresql - "yup it is fine for a user to install an extension - especially if they server is running as the same user trying to install the extension - so go ahead and look in this directory for any possible extensions"

I hope this all makes sense. I also realize this will take some time to make it into Postgresql, but I think multi-tenant systems are going to become more and more common in the future.

Thanks and I look forward to the discussion...
Steve

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-08-18 01:38:57 Re: Feature Request on Extensions
Previous Message Fabrízio de Royes Mello 2013-08-17 21:10:44 Re: Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements