From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org
Subject: Re: pg_parameter_aclcheck() and trusted extensions
In-reply-to: <20220714215225.GA3173833@nathanxps13>
References: <20220706224727.GA2158260@nathanxps13>
 <YsYxEtX8zOYKf3Ru@paquier.xyz> <2995921.1657212060@sss.pgh.pa.us>
 <3126292.1657828950@sss.pgh.pa.us> <20220714215225.GA3173833@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Thu, 14 Jul 2022 14:52:25 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3159280.1657836225.1@sss.pgh.pa.us>
Date: Thu, 14 Jul 2022 18:03:45 -0400
Message-ID: <3159281.1657836225@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3159281.1657836225%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Thu, Jul 14, 2022 at 04:02:30PM -0400, Tom Lane wrote:
>> I noted something that ought to be looked at separately:
>> validate_option_array_item() seems like it needs to be taught about
>> grantable permissions on GUCs.  I think that right now it may report
>> permissions failures in some cases where it should succeed.

> Which cases do you think might be inappropriately reporting permissions
> failures?  It looked to me like this stuff was mostly used for
> pg_db_role_setting, which wouldn't be impacted by the current set of
> grantable GUC permissions.  Is the idea that you should be able to do ALTER
> ROLE SET for GUCs that you have SET permissions for?

Well, that's what I'm wondering.  Obviously that wouldn't *alone* be
enough permissions, but it seems like it could be a component of it.
Specifically, this bit:

	/* manual permissions check so we can avoid an error being thrown */
	if (gconf->context == PGC_USERSET)
		 /* ok */ ;
	else if (gconf->context == PGC_SUSET && superuser())
		 /* ok */ ;
	else if (skipIfNoPermissions)
		return false;

seems like it's trying to duplicate what set_config_option would do,
and it's now missing a component of that.  If it shouldn't check
per-GUC permissions along with superuser(), we should add a comment
explaining why not.

			regards, tom lane