Date: Wed, 6 Jul 2022 15:47:27 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: pgsql-hackers@postgresql.org
Subject: pg_parameter_aclcheck() and trusted extensions
Message-ID: <20220706224727.GA2158260@nathanxps13>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: 
 <https://www.postgresql.org/message-id/20220706224727.GA2158260%40nathanxps13>
Precedence: bulk

Hi hackers,

I found that as of a0ffa88, it's possible to set a PGC_SUSET GUC defined by
a trusted extension as a non-superuser.  I've confirmed that this only
affects v15 and later versions.

	postgres=# CREATE ROLE testuser;
	CREATE ROLE
	postgres=# GRANT CREATE ON DATABASE postgres TO testuser;
	GRANT
	postgres=# SET ROLE testuser;
	SET
	postgres=> SET plperl.on_plperl_init = 'test';
	SET
	postgres=> CREATE EXTENSION plperl;
	CREATE EXTENSION
	postgres=> SELECT setting FROM pg_settings WHERE name = 'plperl.on_plperl_init';
	 setting 
	---------
	 test
	(1 row)

On previous versions, the CREATE EXTENSION command emits the following
WARNING, and the setting does not take effect:

	WARNING:  permission denied to set parameter "plperl.on_plperl_init"

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.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com