Re: Feature Request on Extensions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Feature Request on Extensions
Date
Msg-id 22224.1376842918@sss.pgh.pa.us
Whole thread Raw
In response to Feature Request on Extensions  (Steven Citron-Pousty <spousty@redhat.com>)
Responses Re: Feature Request on Extensions  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Steven Citron-Pousty <spousty@redhat.com> writes:
> What we need is the ability for Postgresql to load extensions from a
> users file space.

TBH this needs a whole lot of thought.  I'm prepared to grant that there
may be other useful security models besides the one we currently have,
but we need to be sure that anything we offer as an alternative is secure
on its own terms and well-thought-out.

The main problem that I'm having with the idea ATM is that I don't see
how we could allow any such capability to non-superusers; isn't the
ability to load chosen code into the server tantamount to superuserdom?
If we restrict it to superusers, and the capability is only effective
for the current session, that seems like it will lead directly to
people running their whole application as superuser.  Which is a place
we don't want to end up at, no matter what the security model is.
So I think that you've underspecified "a user" --- there needs to be
some separation between users who have the ability to create/activate
extensions and users who can use those extensions.

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

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?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgbench / compatibility with old(er) releases
Next
From: Tomas Vondra
Date:
Subject: Re: pgbench / compatibility with old(er) releases