aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/option.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-07-19 17:21:55 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2022-07-19 17:21:55 -0400
commit13d83881514856353dc86575eb0fc28132349a60 (patch)
tree7f00d4e9f3e26cdc9ed38ac7eb9980c27972bcb5 /contrib/postgres_fdw/option.c
parentd6a3aeb9a37bdbb5aa8ed03a9f95e2b1a1b44ba7 (diff)
downloadpostgresql-13d83881514856353dc86575eb0fc28132349a60.tar.gz
postgresql-13d83881514856353dc86575eb0fc28132349a60.zip
Fix missed corner cases for grantable permissions on GUCs.
We allow users to set the values of not-yet-loaded extension GUCs, remembering those values in "placeholder" GUC entries. When/if the extension is loaded later in the session, we need to verify that the user had permissions to set the GUC. That was done correctly before commit a0ffa885e, but as of that commit, we'd check the permissions of the active role when the LOAD happens, not the role that had set the value. (This'd be a security bug if it had made it into a released version.) In principle this is simple enough to fix: we just need to remember the exact role OID that set each GUC value, and use that not GetUserID() when verifying permissions. Maintaining that data in the guc.c data structures is slightly tedious, but fortunately it's all basically just copy-n-paste of the logic for tracking the GucSource of each setting, as we were already doing. Another oversight is that validate_option_array_item() hadn't been taught to check for granted GUC privileges. This appears to manifest only in that ALTER ROLE/DATABASE RESET ALL will fail to reset settings that the user should be allowed to reset. Patch by myself and Nathan Bossart, per report from Nathan Bossart. Back-patch to v15 where the faulty code came in. Discussion: https://postgr.es/m/20220706224727.GA2158260@nathanxps13
Diffstat (limited to 'contrib/postgres_fdw/option.c')
0 files changed, 0 insertions, 0 deletions