Thread: pgsql: Add new GUC createrole_self_grant.
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. Instead, it's a user experience feature. A superuser would necessarily inherit the privileges of any created role and be able to access all such roles via SET ROLE; with this patch, you can configure createrole_self_grant = 'set, inherit' to provide a similar experience for a user who has CREATEROLE but not SUPERUSER. Discussion: https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/e5b8a4c098ad6add39626a14475148872cd687e0 Modified Files -------------- doc/src/sgml/config.sgml | 33 +++++++++ doc/src/sgml/ref/create_role.sgml | 1 + doc/src/sgml/ref/createuser.sgml | 1 + src/backend/commands/user.c | 97 ++++++++++++++++++++++++++- src/backend/utils/misc/guc_tables.c | 12 ++++ src/backend/utils/misc/postgresql.conf.sample | 1 + src/include/commands/user.h | 10 ++- src/test/regress/expected/create_role.out | 33 +++++++++ src/test/regress/sql/create_role.sql | 37 ++++++++++ 9 files changed, 220 insertions(+), 5 deletions(-)
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