diff options
author | Stephen Frost <sfrost@snowman.net> | 2018-05-07 10:10:41 -0400 |
---|---|---|
committer | Stephen Frost <sfrost@snowman.net> | 2018-05-07 10:10:41 -0400 |
commit | 20f01fc45996238f7f1007ba704d30663955150a (patch) | |
tree | f458261249c114157178c7a05d6bab9238cf2ed8 /src/backend/executor/nodeModifyTable.c | |
parent | 83fcc615020647268bb129cbf86f7661feee6412 (diff) | |
download | postgresql-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