Re: Proposal: template-ify (binary) extensions - Mailing list pgsql-hackers

From Markus Wanner
Subject Re: Proposal: template-ify (binary) extensions
Date
Msg-id 51E3F8C3.5020100@bluegap.ch
Whole thread Raw
In response to Re: Proposal: template-ify (binary) extensions  (Markus Wanner <markus@bluegap.ch>)
Responses Re: Proposal: template-ify (binary) extensions
List pgsql-hackers
Robert,

On 07/15/2013 12:12 PM, Markus Wanner wrote:
> On 07/15/2013 05:49 AM, Robert Haas wrote (in a slightly different order):
>> There is a lot of
>> (well-founded, IMHO) resistance to the idea of letting users install C
>> code via an SQL connection.
> 
> Nowhere did I propose anything close to that. I'm in full support of the
> resistance. Pitchforks and torches ready to rumble. :-)

To clarify: In the above agreement, I had the Postgres level ordinary
users in mind, who certainly shouldn't ever be able to upload and run
arbitrary native code.

I'm not quite as enthusiastic if you meant the system level user that
happens to have superuser rights on Postgres. As Andres pointed out,
there are some more holes to plug, if you want to lock down a superuser
account. [1]

I'm not quite clear what kind of "user" you meant in your statement above.

Regards

Markus Wanner


[1]: I see the theoretical benefits of providing yet another layer of
security. Closing the existing holes would require restricting LOAD, but
that seems to suffice (given the sysadmin makes sure he doesn't
accidentally provide any of the harmful extensions).

How about the (optional?) ability to restrict LOAD to directories and
files that are only root writable? Is that enough for a root to disallow
the untrusted Postgres superuser to run arbitrary native code? Or does
that still have other holes? How many real use cases does it break? How
many does it fix?



pgsql-hackers by date:

Previous
From: Robins Tharakan
Date:
Subject: Re: Add some regression tests for SEQUENCE
Next
From: Samrat Revagade
Date:
Subject: Re: Patch for fail-back without fresh backup