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: Joshua Brindle <joshua.brindle@crunchydata.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Shinya Kato <Shinya11.Kato@oss.nttdata.com>, "Bossart, Nathan" <bossartn@amazon.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Jeff Davis <pgsql@j-davis.com>
Date: 2022-01-04T17:07:31Z
Lists: pgsql-hackers 

> On Jan 4, 2022, at 6:35 AM, Joshua Brindle <joshua.brindle@crunchydata.com> wrote:
> 
> I just ran across this and I don't know if it is intended behavior or
> not

<snip>

> postgres=> \password
> Enter new password for user "brindle":
> Enter it again:
> ERROR:  role "brindle" with OID 16384 owns itself

No, that looks like a bug.  Thanks for reviewing!

—
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