2013-09-30 01:41:56 +04:00
|
|
|
/* contrib/hstore/hstore--1.1--1.2.sql */
|
|
|
|
|
|
|
|
-- complain if script is sourced in psql, rather than via ALTER EXTENSION
|
|
|
|
\echo Use "ALTER EXTENSION hstore UPDATE TO '1.2'" to load this file. \quit
|
|
|
|
|
|
|
|
|
|
|
|
-- A version of 1.1 was shipped with these objects mistakenly in 9.3.0.
|
2013-11-10 18:20:52 +04:00
|
|
|
-- Therefore we only add them if we detect that they aren't already there and
|
2013-09-30 01:41:56 +04:00
|
|
|
-- dependent on the extension.
|
|
|
|
|
|
|
|
DO LANGUAGE plpgsql
|
|
|
|
$$
|
Make contrib modules' installation scripts more secure.
Hostile objects located within the installation-time search_path could
capture references in an extension's installation or upgrade script.
If the extension is being installed with superuser privileges, this
opens the door to privilege escalation. While such hazards have existed
all along, their urgency increases with the v13 "trusted extensions"
feature, because that lets a non-superuser control the installation path
for a superuser-privileged script. Therefore, make a number of changes
to make such situations more secure:
* Tweak the construction of the installation-time search_path to ensure
that references to objects in pg_catalog can't be subverted; and
explicitly add pg_temp to the end of the path to prevent attacks using
temporary objects.
* Disable check_function_bodies within installation/upgrade scripts,
so that any security gaps in SQL-language or PL-language function bodies
cannot create a risk of unwanted installation-time code execution.
* Adjust lookup of type input/receive functions and join estimator
functions to complain if there are multiple candidate functions. This
prevents capture of references to functions whose signature is not the
first one checked; and it's arguably more user-friendly anyway.
* Modify various contrib upgrade scripts to ensure that catalog
modification queries are executed with secure search paths. (These
are in-place modifications with no extension version changes, since
it is the update process itself that is at issue, not the end result.)
Extensions that depend on other extensions cannot be made fully secure
by these methods alone; therefore, revert the "trusted" marking that
commit eb67623c9 applied to earthdistance and hstore_plperl, pending
some better solution to that set of issues.
Also add documentation around these issues, to help extension authors
write secure installation scripts.
Patch by me, following an observation by Andres Freund; thanks
to Noah Misch for review.
Security: CVE-2020-14350
2020-08-10 17:44:42 +03:00
|
|
|
DECLARE
|
|
|
|
my_schema pg_catalog.text := pg_catalog.quote_ident(pg_catalog.current_schema());
|
|
|
|
old_path pg_catalog.text := pg_catalog.current_setting('search_path');
|
2013-09-30 01:41:56 +04:00
|
|
|
BEGIN
|
Make contrib modules' installation scripts more secure.
Hostile objects located within the installation-time search_path could
capture references in an extension's installation or upgrade script.
If the extension is being installed with superuser privileges, this
opens the door to privilege escalation. While such hazards have existed
all along, their urgency increases with the v13 "trusted extensions"
feature, because that lets a non-superuser control the installation path
for a superuser-privileged script. Therefore, make a number of changes
to make such situations more secure:
* Tweak the construction of the installation-time search_path to ensure
that references to objects in pg_catalog can't be subverted; and
explicitly add pg_temp to the end of the path to prevent attacks using
temporary objects.
* Disable check_function_bodies within installation/upgrade scripts,
so that any security gaps in SQL-language or PL-language function bodies
cannot create a risk of unwanted installation-time code execution.
* Adjust lookup of type input/receive functions and join estimator
functions to complain if there are multiple candidate functions. This
prevents capture of references to functions whose signature is not the
first one checked; and it's arguably more user-friendly anyway.
* Modify various contrib upgrade scripts to ensure that catalog
modification queries are executed with secure search paths. (These
are in-place modifications with no extension version changes, since
it is the update process itself that is at issue, not the end result.)
Extensions that depend on other extensions cannot be made fully secure
by these methods alone; therefore, revert the "trusted" marking that
commit eb67623c9 applied to earthdistance and hstore_plperl, pending
some better solution to that set of issues.
Also add documentation around these issues, to help extension authors
write secure installation scripts.
Patch by me, following an observation by Andres Freund; thanks
to Noah Misch for review.
Security: CVE-2020-14350
2020-08-10 17:44:42 +03:00
|
|
|
-- for safety, transiently set search_path to just pg_catalog+pg_temp
|
|
|
|
PERFORM pg_catalog.set_config('search_path', 'pg_catalog, pg_temp', true);
|
2013-09-30 01:41:56 +04:00
|
|
|
|
|
|
|
PERFORM 1
|
|
|
|
FROM pg_proc p
|
|
|
|
JOIN pg_depend d
|
|
|
|
ON p.proname = 'hstore_to_json_loose'
|
2013-09-30 19:33:54 +04:00
|
|
|
AND d.classid = 'pg_proc'::regclass
|
2013-09-30 01:41:56 +04:00
|
|
|
AND d.objid = p.oid
|
|
|
|
AND d.refclassid = 'pg_extension'::regclass
|
|
|
|
JOIN pg_extension x
|
|
|
|
ON d.refobjid = x.oid
|
|
|
|
AND x.extname = 'hstore';
|
|
|
|
|
|
|
|
IF NOT FOUND
|
2013-11-10 18:20:52 +04:00
|
|
|
THEN
|
Make contrib modules' installation scripts more secure.
Hostile objects located within the installation-time search_path could
capture references in an extension's installation or upgrade script.
If the extension is being installed with superuser privileges, this
opens the door to privilege escalation. While such hazards have existed
all along, their urgency increases with the v13 "trusted extensions"
feature, because that lets a non-superuser control the installation path
for a superuser-privileged script. Therefore, make a number of changes
to make such situations more secure:
* Tweak the construction of the installation-time search_path to ensure
that references to objects in pg_catalog can't be subverted; and
explicitly add pg_temp to the end of the path to prevent attacks using
temporary objects.
* Disable check_function_bodies within installation/upgrade scripts,
so that any security gaps in SQL-language or PL-language function bodies
cannot create a risk of unwanted installation-time code execution.
* Adjust lookup of type input/receive functions and join estimator
functions to complain if there are multiple candidate functions. This
prevents capture of references to functions whose signature is not the
first one checked; and it's arguably more user-friendly anyway.
* Modify various contrib upgrade scripts to ensure that catalog
modification queries are executed with secure search paths. (These
are in-place modifications with no extension version changes, since
it is the update process itself that is at issue, not the end result.)
Extensions that depend on other extensions cannot be made fully secure
by these methods alone; therefore, revert the "trusted" marking that
commit eb67623c9 applied to earthdistance and hstore_plperl, pending
some better solution to that set of issues.
Also add documentation around these issues, to help extension authors
write secure installation scripts.
Patch by me, following an observation by Andres Freund; thanks
to Noah Misch for review.
Security: CVE-2020-14350
2020-08-10 17:44:42 +03:00
|
|
|
PERFORM pg_catalog.set_config('search_path', old_path, true);
|
2013-09-30 01:41:56 +04:00
|
|
|
|
|
|
|
CREATE FUNCTION hstore_to_json(hstore)
|
|
|
|
RETURNS json
|
|
|
|
AS 'MODULE_PATHNAME', 'hstore_to_json'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE CAST (hstore AS json)
|
|
|
|
WITH FUNCTION hstore_to_json(hstore);
|
|
|
|
|
|
|
|
CREATE FUNCTION hstore_to_json_loose(hstore)
|
|
|
|
RETURNS json
|
|
|
|
AS 'MODULE_PATHNAME', 'hstore_to_json_loose'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
END IF;
|
|
|
|
|
Make contrib modules' installation scripts more secure.
Hostile objects located within the installation-time search_path could
capture references in an extension's installation or upgrade script.
If the extension is being installed with superuser privileges, this
opens the door to privilege escalation. While such hazards have existed
all along, their urgency increases with the v13 "trusted extensions"
feature, because that lets a non-superuser control the installation path
for a superuser-privileged script. Therefore, make a number of changes
to make such situations more secure:
* Tweak the construction of the installation-time search_path to ensure
that references to objects in pg_catalog can't be subverted; and
explicitly add pg_temp to the end of the path to prevent attacks using
temporary objects.
* Disable check_function_bodies within installation/upgrade scripts,
so that any security gaps in SQL-language or PL-language function bodies
cannot create a risk of unwanted installation-time code execution.
* Adjust lookup of type input/receive functions and join estimator
functions to complain if there are multiple candidate functions. This
prevents capture of references to functions whose signature is not the
first one checked; and it's arguably more user-friendly anyway.
* Modify various contrib upgrade scripts to ensure that catalog
modification queries are executed with secure search paths. (These
are in-place modifications with no extension version changes, since
it is the update process itself that is at issue, not the end result.)
Extensions that depend on other extensions cannot be made fully secure
by these methods alone; therefore, revert the "trusted" marking that
commit eb67623c9 applied to earthdistance and hstore_plperl, pending
some better solution to that set of issues.
Also add documentation around these issues, to help extension authors
write secure installation scripts.
Patch by me, following an observation by Andres Freund; thanks
to Noah Misch for review.
Security: CVE-2020-14350
2020-08-10 17:44:42 +03:00
|
|
|
PERFORM pg_catalog.set_config('search_path', old_path, true);
|
2013-09-30 01:41:56 +04:00
|
|
|
END;
|
|
|
|
|
|
|
|
$$;
|