Horton

Re: CREATEROLE and role ownership hierarchies

Mark Dilger <mark.dilger@enterprisedb.com>

View thread View on postgr.es
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, "Bossart, Nathan" <bossartn@amazon.com>, Jeff Davis <pgsql@j-davis.com>, Joshua Brindle <joshua.brindle@crunchydata.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Shinya Kato <Shinya11.Kato@oss.nttdata.com>
Date: 2022-01-24T22:49:34Z
Lists: pgsql-hackers 

> On Jan 24, 2022, at 2:21 PM, Stephen Frost <sfrost@snowman.net> wrote:
> 
> Being able to create and drop users is, in fact, effectively a superuser-only task today.  We could throw out the entire idea of role ownership, in fact, as being entirely unnecessary when talking about that specific task.

Wow, that's totally contrary to how I see this patch.  The heart and soul of this patch is to fix the fact that CREATEROLE is currently overpowered.  Everything else is gravy.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Make role grant system more consistent with other privileges.

  2. Ensure that pg_auth_members.grantor is always valid.

  3. Remove the ability of a role to administer itself.

  4. Add tests of the CREATEROLE attribute

  5. Replace explicit PIN entries in pg_depend with an OID range test.

  6. Shore up ADMIN OPTION restrictions.

  7. Add pg_has_role() family of privilege inquiry functions modeled after the

  8. Align GRANT/REVOKE behavior more closely with the SQL spec, per discussion