On Thu, Jul 07, 2022 at 10:04:18AM +0900, Michael Paquier wrote:
> 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.
Thanks. I've been thinking about this one a bit. For simple cases like
plperl, it would be easy enough to temporarily revert the superuser switch
when calling _PG_init() or one of the DefineCustomXXXVariable functions.
Unfortunately, I think there are more complicated scenarios. For example,
what role should pg_parameter_aclmask() use when a trusted extension script
loads a library after SET ROLE? The original user might not ordinarily be
able to assume this role, so the trusted extension script could still be a
way to set parameters you don't have privileges for. Should we just always
use the role that's calling CREATE EXTENSION?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
