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
