postgresql/contrib/adminpack/adminpack--1.0--1.1.sql

/* contrib/adminpack/adminpack--1.0--1.1.sql */

-- complain if script is sourced in psql, rather than via ALTER EXTENSION
\echo Use "ALTER EXTENSION adminpack UPDATE TO '1.1'" to load this file. \quit

REVOKE EXECUTE ON FUNCTION pg_catalog.pg_logfile_rotate() FROM PUBLIC;
adminpack: Revoke EXECUTE on pg_logfile_rotate() In 9.6, we moved a number of functions over to using the GRANT system to control access instead of having hard-coded superuser checks. As it turns out, adminpack was creating another function in the catalog for one of those backend functions where the superuser check was removed, specifically pg_rotate_logfile(), but it didn't get the memo about having to REVOKE EXECUTE on the alternative-name function (pg_logfile_rotate()), meaning that in any installations with adminpack on 9.6 and higher, any user is able to run the pg_logfile_rotate() function, which then calls pg_rotate_logfile() and rotates the logfile. Fix by adding a new version of adminpack (1.1) which handles the REVOKE. As this function should have only been available to the superuser, this is a security issue, albeit a minor one. Security: CVE-2018-1115 2018-05-07 16:10:45 +02:00			`/* contrib/adminpack/adminpack--1.0--1.1.sql */`

			`-- complain if script is sourced in psql, rather than via ALTER EXTENSION`
			`\echo Use "ALTER EXTENSION adminpack UPDATE TO '1.1'" to load this file. \quit`

			`REVOKE EXECUTE ON FUNCTION pg_catalog.pg_logfile_rotate() FROM PUBLIC;`