Re: in-catalog Extension Scripts and Control parameters (templates?) - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: in-catalog Extension Scripts and Control parameters (templates?)
Date
Msg-id m2fvz8ncn5.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Dumping an Extension's Script  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: in-catalog Extension Scripts and Control parameters (templates?)
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> I'm quite worried about the security ramifications of this patch. Today, if
> you're not sure if a system has e.g sslinfo installed, you can safely just
> run "CREATE EXTENSION sslinfo". With this patch, that's no longer true,
> because "foo" might not be the extension you're looking for. Mallory

With the attached patch, you can't create a template for an extension
that is already available, so to protect against your scenario you only
have to make "sslinfo" available.

Please also note that when actually installing the "sslinfo" extension,
the one from the system will get prefered over the one from the
templates, should you have both available.

Now, I can see why you would still think it's not enough. Baring better
ideas, the current patch restricts the feature to superusers.

> Documentation doesn't build, multiple errors. In addition to the reference
> pages, there should be a section in the main docs about these templates.

I'm now working on that, setting up the documentation tool set.

>> postgres=# create template for extension myextension version '1.0' with () as 'foobar';
>> CREATE TEMPLATE FOR EXTENSION
>> postgres=# create extension myextension;
>> ERROR:  syntax error at or near "foobar"
>> LINE 1: create extension myextension;
>>         ^
>
> Confusing error message.

Introducing a syntax error in hstore--1.1.sql leads to the same message.
Even if we agree that it must be changed, I think that's for another
patch.

    ~# create extension hstore;
    ERROR:  syntax error at or near "foobar" at character 115
    STATEMENT:  create extension hstore;
    ERROR:  syntax error at or near "foobar"

>> postgres=# create template for extension myextension version '1.0' with () as $$create table foobar(i int4) $$;
>> CREATE TEMPLATE FOR EXTENSION
>> postgres=# create extension myextension;
>> CREATE EXTENSION
>> postgres=# select * from foobar;
>> ERROR:  relation "foobar" does not exist
>> LINE 1: select * from foobar;
>>                       ^
>
> Where did that table go?

The control->schema was not properly initialized when not given by the
user. That's fixed, and I added a regression test.

> Ah, here... Where did that "    1.0" schema come from?

Fixed too, was the same bug.

>> postgres=> create template for extension myextension version '1.0' with
>> (schema public) as $$ create function evilfunc() returns int4 AS
>> evilfunc' language internal; $$;
>> CREATE TEMPLATE FOR EXTENSION
>> postgres=> create extension myextension version '1.0';ERROR:  permission denied for language internal
>> postgres=> drop template for extension myextension version '1.0';
>> ERROR:  extension with OID 16440 does not exist
>
> Something wrong with catalog caching.

Works for me, I couldn't reproduce the bug here, working from Álvaro's
version 4 of the patch. Maybe he did already fix it, and you tested my
version 3?

>> $ make -s  install
>> /usr/bin/install: cannot stat `./hstore--1.0.sql': No such file or directory
>> make: *** [install] Error 1
>
> Installing hstore fails.

Fixed in the attached. Seeing that makes me think that you actually used
Álvaro's version 4, though.

>> postgres=> create template for extension sslinfo version '1.0' with
>> (schema public) as $$ create function evilfunc() returns int4 AS
>> evilfunc' language internal; $$;
>> ERROR:  extension "sslinfo" is already available

Expected.

>> postgres=> create template for extension sslinfo2 version '1.0' with
>> (schema public) as $$ create function evilfunc() returns int4 AS
>> evilfunc' language internal; $$;
>> CREATE TEMPLATE FOR EXTENSION
>> postgres=> alter template for extension sslinfo2 rename to sslinfo;
>> ALTER TEMPLATE FOR EXTENSION
>
> If we check for an existing extension at CREATE, should also check for that
> in ALTER ... RENAME TO.

Indeed, good catch. Fixed in the attached version 5 of the patch.

I didn't add a regression test for that case, because we need to know
which extensions are available when we try to obtain this error, and I
don't know how to do that. We could create a template for the extension
foobar, then foobar2, then rename foobar2 to foobar, but that wouldn't
exercise the same code path.

Thanks again for your reviewing,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


Attachment

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Spin Lock sleep resolution
Next
From: Peter Eisentraut
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]