Date: Thu, 7 Jul 2022 09:49:21 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@postgresql.org
Subject: Re: pg_parameter_aclcheck() and trusted extensions
Message-ID: <20220707164921.GA2251016@nathanxps13>
References: <20220706224727.GA2158260@nathanxps13>
 <YsYxEtX8zOYKf3Ru@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YsYxEtX8zOYKf3Ru@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/20220707164921.GA2251016%40nathanxps13>
Precedence: bulk

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