Steven Citron-Pousty <spou...@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 we runs 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
