Horton
Menu

Re: Allow placeholders in ALTER ROLE w/o superuser

Alexander Korotkov <aekorotkov@gmail.com>

View thread
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, nathandbossart@gmail.com, steve@supabase.io, pgsql-hackers@postgresql.org
Date: 2022-11-19T01:02:04Z
Lists: pgsql-hackers 
On Sat, Nov 19, 2022 at 12:41 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ... BTW, re-reading the commit message for a0ffa885e:
>
>     One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege
>     --- one could wish that those were handled by a revocable grant to
>     PUBLIC, but they are not, because we couldn't make it robust enough
>     for GUCs defined by extensions.
>
> it suddenly struck me to wonder if the later 13d838815 changed the
> situation enough to allow revisiting that problem, and/or if storing
> the source role's OID in pg_db_role_setting would help.
>
> I don't immediately recall all the problems that led us to leave USERSET
> GUCs out of the feature, so maybe this is nuts; but maybe it isn't.
> It'd be worth considering if we're trying to improve matters here.

I think if we implement the user-visible USERSET flag for ALTER ROLE,
then we might just check permissions for such parameters from the
target role.

------
Regards,
Alexander Korotkov

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove extra regress check arguments from test_pg_db_role_setting

  2. meson: Add 'running' test setup, as a replacement for installcheck

  3. Add USER SET parameter values for pg_db_role_setting

  4. Fix sloppy cleanup of roles in privileges.sql.

  5. Drop test user when done with it.

  6. GRANT rights to CURRENT_USER instead of adding roles

  7. Clean up roles from roleattributes test

  8. Make repeated 'make installcheck' runs work