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

From Heikki Linnakangas
Subject Re: in-catalog Extension Scripts and Control parameters (templates?)
Date
Msg-id 5152FF3D.4000401@vmware.com
Whole thread Raw
In response to Re: in-catalog Extension Scripts and Control parameters (templates?)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: in-catalog Extension Scripts and Control parameters (templates?)
Re: in-catalog Extension Scripts and Control parameters (templates?)
Re: in-catalog Extension Scripts and Control parameters (templates?)
List pgsql-hackers
On 15.03.2013 23:00, Alvaro Herrera wrote:
> Dimitri Fontaine wrote:
>
>> Please find attached v3 of the Extension Templates patch, with full
>> pg_dump support thanks to having merged default_full_version, appended
>> with some regression tests now that it's possible.
>
> Here's a rebased version; there were some merge conflicts with master.
> I also fixed some compiler warnings.

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 might've done this:

create template for extension sslinfo version '1.0' with (schema public) 
as $$ DO EVIL STUFF $$;

Now if you run "CREATE EXTENSION sslinfo" as superuser, you've been 
compromised. This is not only a problem when sitting at a psql console, 
it also just became really dangerous to run pg_dump backups without 
ensuring that all the extensions are installed beforehand. That's 
exactly the situation we wanted to avoid when extensions were introduced 
in the first place.

Things get even more complicated if there's version 1.0 of sslinfo 
already installed, and you create an extension template for sslinfo 
version 1.1. Is that possible? How does it behave?

Below are some random bugs that I bumped into while testing. These could 
be fixed, but frankly I think this should be rejected for security reasons.


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

> 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.

> 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?

> postgres=# create template for extension myextension version '1.0' with () as $$ create function myfunc() returns
int4AS $f$ select 123; $f$ language sql; $$;
 
> CREATE TEMPLATE FOR EXTENSION
> postgres=# create extension myextension version '1.0';
> CREATE EXTENSION
> postgres=# select * from pg_namespace;      nspname       | nspowner |            nspacl
> --------------------+----------+-------------------------------
>  pg_toast           |       10 |
>  pg_temp_1          |       10 |
>  pg_toast_temp_1    |       10 |
>  pg_catalog         |       10 | {heikki=UC/heikki,=U/heikki}
>  public             |       10 | {heikki=UC/heikki,=UC/heikki}
>  information_schema |       10 | {heikki=UC/heikki,=U/heikki}
>          1.0        |       10 |
> (7 rows)

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

> 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.

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

Installing hstore fails.

> postgres=> create template for extension sslinfo version '1.0' with (schema public) as $$ create function evilfunc()
returnsint4 AS 'evilfunc' language internal; $$;
 
> ERROR:  extension "sslinfo" is already available
> postgres=> create template for extension sslinfo2 version '1.0' with (schema public) as $$ create function evilfunc()
returnsint4 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.

- Heikki



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
Next
From: Michael Paquier
Date:
Subject: Re: [COMMITTERS] pgsql: Allow external recovery_config_directory