2010-09-21 04:08:53 +08:00
|
|
|
# contrib/adminpack/Makefile
|
2007-02-10 01:04:00 +08:00
|
|
|
|
2006-05-31 05:34:15 +08:00
|
|
|
MODULE_big = adminpack
|
2014-07-15 02:07:52 +08:00
|
|
|
OBJS = adminpack.o $(WIN32RES)
|
2011-02-14 09:06:41 +08:00
|
|
|
PG_CPPFLAGS = -I$(libpq_srcdir)
|
|
|
|
|
|
|
|
|
|
EXTENSION = adminpack
|
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.
In HEAD, move the changes implemented for adminpack up to be adminpack
2.0 instead of 1.1.
Security: CVE-2018-1115
2018-05-07 22:10:33 +08:00
|
|
|
DATA = adminpack--1.0.sql adminpack--1.0--1.1.sql adminpack--1.1--2.0.sql
|
2014-07-15 02:07:52 +08:00
|
|
|
PGFILEDESC = "adminpack - support functions for pgAdmin"
|
2006-05-31 05:34:15 +08:00
|
|
|
|
2017-08-12 09:04:04 +08:00
|
|
|
REGRESS = adminpack
|
|
|
|
|
|
2006-05-31 05:34:15 +08:00
|
|
|
ifdef USE_PGXS
|
2007-06-27 06:05:04 +08:00
|
|
|
PG_CONFIG = pg_config
|
|
|
|
|
PGXS := $(shell $(PG_CONFIG) --pgxs)
|
2006-05-31 05:34:15 +08:00
|
|
|
include $(PGXS)
|
|
|
|
|
else
|
|
|
|
|
subdir = contrib/adminpack
|
|
|
|
|
top_builddir = ../..
|
|
|
|
|
include $(top_builddir)/src/Makefile.global
|
|
|
|
|
include $(top_srcdir)/contrib/contrib-global.mk
|
|
|
|
|
endif
|
