Re: Proposal: template-ify (binary) extensions

On 2013-07-14 23:49:47 -0400, Robert Haas wrote:
> On Fri, Jul 5, 2013 at 4:27 PM, Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> > One way to resolve that - and that seems to be the direction Dimitri's
> > patch is going - is to make the extension depend on its template. (And
> > thereby breaking the mental model of a template, IMO. In the spirit of
> > that mental model, one could argue that code for stored procedures
> > shouldn't be duplicated, but instead just reference its ancestor.)
>
> The security problems with this model have been discussed in every
> email thread about the extension template feature. There is a lot of
> (well-founded, IMHO) resistance to the idea of letting users install C
> code via an SQL connection.

I still fail how to see that that argument has much merits:
CREATE EXTENSION adminpack;
CREATE OR REPLACE FUNCTION pg_catalog.pg_binary_file_write(text, bytea, boolean)
RETURNS bigint
LANGUAGE c
STRICT
AS '$libdir/adminpack', $function$pg_file_write$function$

SELECT pg_binary_file_write('some-path.so', 'some-so-as-bytea'::bytea, 1);
LOAD '/var/lib/postgresql/9.2/main/some-path.so';

All done with the default contribs, without even a PL. It's obviously
even more trivial if you have access to plpython or plperlu. You can do
similar nastiness without even contrib installed misusing binary COPY or
possibly even using tuplesort tapes.

A superuser can execute native code as postges user. That's it.

Now, I don't think Markus proposal is a good idea on *other* grounds
though... but that's for another email.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services