Re: Allow placeholders in ALTER ROLE w/o superuser - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Allow placeholders in ALTER ROLE w/o superuser
Date
Msg-id 20220701234027.GA637814@nathanxps13
Whole thread Raw
In response to Allow placeholders in ALTER ROLE w/o superuser  (Steve Chavez <steve@supabase.io>)
Responses Re: Allow placeholders in ALTER ROLE w/o superuser
List pgsql-hackers
On Sun, Jun 05, 2022 at 11:20:38PM -0500, Steve Chavez wrote:
> However, defining placeholders at the role level require superuser:
> 
>   alter role myrole set my.username to 'tomas';
>   ERROR:  permission denied to set parameter "my.username"
> 
> Which is inconsistent and surprising behavior. I think it doesn't make
> sense since you can already set them at the session or transaction
> level(SET LOCAL my.username = 'tomas'). Enabling this would allow sidecar
> services to store metadata scoped to its pertaining role.
> 
> I've attached a patch that removes this restriction. From my testing, this
> doesn't affect permission checking when an extension defines its custom GUC
> variables.
> 
>    DefineCustomStringVariable("my.custom", NULL, NULL,  &my_custom,  NULL,
>       PGC_SUSET, ..);
> 
> Using PGC_SUSET or PGC_SIGHUP will fail accordingly. Also no tests fail
> when doing "make installcheck".

IIUC you are basically proposing to revert a6dcd19 [0], but it is not clear
to me why that is safe.  Am I missing something?

[0] https://www.postgresql.org/message-id/flat/4090.1258042387%40sss.pgh.pa.us

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: margay fails assertion in stats/dsa/dsm code
Next
From: Justin Pryzby
Date:
Subject: Re: should check interrupts in BuildRelationExtStatistics ?