aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorStephen Frost <sfrost@snowman.net>2018-05-07 10:10:41 -0400
committerStephen Frost <sfrost@snowman.net>2018-05-07 10:10:41 -0400
commit20f01fc45996238f7f1007ba704d30663955150a (patch)
treef458261249c114157178c7a05d6bab9238cf2ed8 /src/backend/executor/nodeModifyTable.c
parent83fcc615020647268bb129cbf86f7661feee6412 (diff)
downloadpostgresql-20f01fc45996238f7f1007ba704d30663955150a.tar.gz
postgresql-20f01fc45996238f7f1007ba704d30663955150a.zip
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
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions