diff options
| author | Stephen Frost | 2018-05-07 14:10:33 +0000 |
|---|---|---|
| committer | Stephen Frost | 2018-05-07 14:10:33 +0000 |
| commit | 7b347409fa2776fbaa4ec9c57365f48a2bbdb80c (patch) | |
| tree | 9eea172346f25095c22597de79998277bdf6b2b4 /contrib/adminpack/adminpack.control | |
| parent | f955d7ee166dfa053caa6d1bdb2a28b28b212fe3 (diff) | |
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
Diffstat (limited to 'contrib/adminpack/adminpack.control')
| -rw-r--r-- | contrib/adminpack/adminpack.control | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/contrib/adminpack/adminpack.control b/contrib/adminpack/adminpack.control index 71f6ad5ddf9..12569dcdd71 100644 --- a/contrib/adminpack/adminpack.control +++ b/contrib/adminpack/adminpack.control @@ -1,6 +1,6 @@ # adminpack extension comment = 'administrative functions for PostgreSQL' -default_version = '1.1' +default_version = '2.0' module_pathname = '$libdir/adminpack' relocatable = false schema = pg_catalog |
