|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Nathan Bossart <nathandbossart(at)gmail(dot)com>|
|Cc:||Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: pg_parameter_aclcheck() and trusted extensions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Nathan Bossart <nathandbossart(at)gmail(dot)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)
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
|Next Message||Bruce Momjian||2022-07-14 22:31:31||Re: [PATCH v1] remove redundant check of item pointer|
|Previous Message||Nathan Bossart||2022-07-14 21:52:25||Re: pg_parameter_aclcheck() and trusted extensions|