This extension implements extension whitelisting, and will actively prevent
users from installing extensions not in the provided list. Also, this
extension implements a form of sudo
facility in that the whitelisted
extensions will get installed as if superuser. Privileges are dropped
before handing the control back to the user.
The operations CREATE EXTENSION
, DROP EXTENSION
and ALTER EXTENSION ... UPDATE
are run by superuser. The ALTER EXTENSION ... ADD|DROP
command
is intentionnaly not supported so as not to allow users to modify an already
installed extension. That means that it's not currently possible to CREATE EXTENSION ... FROM 'unpackaged';
.
Note that the extension script is running as if run by a stored procedure
owned by your bootstrap superuser and with SECURITY DEFINER
, meaning
that the extension and all its objects are owned by this superuser.
The pgextwlist
PostgreSQL extension is released under
The PostgreSQL Licence, a
liberal Open Source license, similar to the BSD or MIT licenses.
-
Install the server development packages (on Ubuntu, this would look like
apt-get install postgresql-server-dev-all
) -
then:
make sudo make install
This will generate a pgextwlist.so
shared library that you will have to
install in
`pg_config --pkglibdir`/plugins
so that your backend loads it automatically.
You need to define the list of extensions that are whitelisted, the user that performs the extension installing, and the error behavior.
-
local_preload_libraries
Add
pgextwlist
to thelocal_preload_libraries
setting. Don't forget to add the module in the$plugin
directory. -
custom_variable_classes
Add
extwlist
to thecustom_variable_classes
setting if you're using 9.1, in 9.2 this setting disappeared. -
extwlist.extensions
List of extensions allowed for installation.
-
extwlist.custom_path
Filesystem path where to look for custom scripts.
That's quite simple:
$ edit postgresql.conf to add local_preload_libraries, custom_variable_classes and extwlist.extensions
dim=# show extwlist.extensions;
show extwlist.extensions;
extwlist.extensions
---------------------
hstore,cube
(1 row)
dim=# create extension foo;
create extension foo;
ERROR: extension "foo" is not whitelisted
DETAIL: Installing the extension "foo" failed, because it is not on the whitelist of user-installable extensions.
HINT: Your system administrator has allowed users to install certain extensions. See: SHOW extwlist.extensions;
dim=# create extension hstore;
create extension hstore;
WARNING: => is deprecated as an operator name
DETAIL: This name may be disallowed altogether in future versions of PostgreSQL.
CREATE EXTENSION
dim=# \dx
\dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------------
hstore | 1.0 | public | data type for storing sets of (key, value) pairs
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)
Even if you're not superuser:
dim=> select rolsuper from pg_roles where rolname = current_user;
select rolsuper from pg_roles where rolname = current_user;
rolsuper
----------
f
(1 row)
dim=> create extension hstore;
create extension hstore;
WARNING: => is deprecated as an operator name
DETAIL: This name may be disallowed altogether in future versions of PostgreSQL.
CREATE EXTENSION
dim=> create extension earthdistance;
create extension earthdistance;
ERROR: extension "earthdistance" is not whitelisted
DETAIL: Installing the extension "earthdistance" failed, because it is not on the whitelist of user-installable extensions.
HINT: Your system administrator has allowed users to install certain extensions. SHOW extwlist.extensions;
dim=> \dx
\dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------------
hstore | 1.0 | public | data type for storing sets of (key, value) pairs
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)
dim=> drop extension hstore;
drop extension hstore;
DROP EXTENSION
Some extensions are installing objects that only the superuser can make use of by default, it's then a good idea to tweak permissions and grant usage to the current_user or even the database owner, depending.
The custom scripts feature allows to do that by providing scripts to be run around the execution of the extension's script itself.
For the creation of extension extname
version 1.0
the following scripts
will be used when they do exist, as shown here:
#. ${extwlist.custom_path}/extname/before--1.0.sql
#. ${extwlist.custom_path}/extname/before-create.sql
, only when the
previous one, specific to the version being installed, does not exists.
#. The CREATE EXTENSION
command now runs normally
#. ${extwlist.custom_path}/extname/after--1.0.sql
#. ${extwlist.custom_path}/extname/after-create.sql
For the update of extension extname
from version 1.0
to version 1.1
the following scripts will be used when they do exist, as shown here:
#. ${extwlist.custom_path}/extname/before--1.0--1.1.sql
#. ${extwlist.custom_path}/extname/before-update.sql
, only when the
previous one does not exists.
#. The ALTER EXTENSION UPDATE
command now runs normally
#. ${extwlist.custom_path}/extname/after--1.0--1.1.sql
#. ${extwlist.custom_path}/extname/after-update.sql
only when the
previous one, specific to the versions being considered, does not
exists.
Before executing them, the extwlist extension applies the following substitions to the custom scripts:
-
any line that begins with
\echo
is removed, -
the literal
@extschema@
is unconditionnaly replaced by the current schema being used to create the extension objects, -
the literal
@current_user@
is replaced by the name of the current user, -
the literal
@database_owner@
is replaced by the name of the current database owner.
Tip: remember that you can execute DO
blocks if you need dynamic sql.
The whitelisting works by overloading the ProcessUtility_hook
and gaining
control each time a utility statement is issued. When this statement is a
CREATE EXTENSION
, the extension's name is extracted from the parsetree
and checked against the whitelist. Superuser is obtained as in the usual
SECURITY DEFINER
case, except hard coded to target the bootstrap user.