Re: pgsql: Add new GUC createrole_self_grant.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <rhaas(at)postgresql(dot)org>
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add new GUC createrole_self_grant.
Date: 2023-01-11 01:47:10
Message-ID: 399118.1673401630@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <rhaas(at)postgresql(dot)org> writes:
> Add new GUC createrole_self_grant.
> Can be set to the empty string, or to either or both of "set" or
> "inherit". If set to a non-empty value, a non-superuser who creates
> a role (necessarily by relying up the CREATEROLE privilege) will
> grant that role back to themselves with the specified options.

> This isn't a security feature, because the grant that this feature
> triggers can also be performed explicitly.

[ squint ... ] Are you sure it's not a security *hazard*, though?

It troubles me that we're introducing a command-semantics-altering
GUC at all; we have substantial experience with regretting such
choices. It troubles me more that the semantics change bears on
security matters, and even more that you've made it USERSET.
That at least opens the door to unprivileged user X causing code
belonging to more-privileged user Y to do something other than
what Y expected.

I'll hold my tongue if you're willing to make it SUSET or higher.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2023-01-11 02:26:17 Re: pgsql: Add new GUC createrole_self_grant.
Previous Message Michael Paquier 2023-01-11 00:56:56 pgsql: Avoid using tuple from syscache for update of pg_database.datfro

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2023-01-11 02:07:05 Spinlock is missing when updating two_phase of ReplicationSlot
Previous Message Peter Geoghegan 2023-01-11 01:36:29 Re: Fixing a couple of buglets in how VACUUM sets visibility map bits