Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Jul 06, 2022 at 03:47:27PM -0700, Nathan Bossart wrote:
>> I think the call to superuser_arg() in pg_parameter_aclmask() is causing
>> set_config_option() to bypass the normal privilege checks, as
>> execute_extension_script() will have set the user ID to the bootstrap
>> superuser for trusted extensions like plperl. I don't have a patch or a
>> proposal at the moment, but I thought it was worth starting the discussion.
> Looks like a bug to me, so I have added an open item assigned to Tom.
Yeah. So the fix here seems pretty obvious: rather than applying the
permissions check using bare GetUserId(), we need to remember the role
OID that originally applied the setting, and use that.
The problem with this sketch is that
(1) we need an OID field in struct config_generic, as well as GucStack,
which means an ABI break for any extensions that look directly at GUC
records. There probably aren't many, but ...
(2) we need an additional parameter to set_config_option, which
again is a compatibility break for anything calling that directly.
There surely are such callers --- our own extensions do it.
Can we get away with doing these things in beta3? We could avoid
breaking (2) in the v15 branch by making set_config_option into
a wrapper around set_config_option_ext, or something like that;
but the problem with struct config_generic seems inescapable.
(Putting the new field at the end would solve nothing, since
config_generic is embedded into larger structs.)
The alternative to API/ABI breaks seems to be to revert the
feature, which would be sad.
regards, tom lane