Re: Allow placeholders in ALTER ROLE w/o superuser

Alexander Korotkov <aekorotkov@gmail.com>

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-20T17:48:04Z
Lists: pgsql-hackers

Attachments

On Sat, Nov 19, 2022 at 4:02 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> 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.

I've drafted a patch implementing ALTER ROLE ... SET ... TO ... USER SET syntax.

These options are working only for USERSET GUC variables, but require
less privileges to set.  I think there is no problem to implement

Also it seems that this approach doesn't conflict with future
privileges for USERSET GUCs [1].  I expect that USERSET GUCs should be
available unless explicitly REVOKEd.  That mean we should be able to
check those privileges during ALTER ROLE.

Opinions on the patch draft?

Links
1. https://mail.google.com/mail/u/0/?ik=a20b091faa&view=om&permmsgid=msg-f%3A1749871710745577015

------
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