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: