Re: pgsql: Add new GUC createrole_self_grant.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <rhaas@postgresql.org>
Cc: pgsql-committers@lists.postgresql.org
Date: 2023-01-11T01:47:10Z
Lists: pgsql-hackers
Robert Haas <rhaas@postgresql.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
Commits
-
Assorted improvements to SECURITY DEFINER functions documentation.
- 6fa66ec88ff2 16.0 landed
-
Add new GUC createrole_self_grant.
- e5b8a4c098ad 16.0 cited