Horton

Re: pg_auth_members.grantor is bunk

Jeff Davis <pgsql@j-davis.com>

View thread View on postgr.es
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jacob Champion <jchampion@timescale.com>, Stephen Frost <sfrost@snowman.net>, "David G. Johnston" <david.g.johnston@gmail.com>, Mark Dilger <mark.dilger@enterprisedb.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-09-07T14:56:28Z
Lists: pgsql-hackers 
On Wed, 2022-09-07 at 09:39 -0400, Robert Haas wrote:
> Now that is not to say that we couldn't decide that
> select_best_grantor() got it wrong and choose to break backward
> compatibility in order to fix it ... but I'm not even convinced that
> the alternative behavior you propose is clearly better, let alone
> that
> it's enough better to justify changing things.

OK. I suppose the best path forward is to just try to improve the
ability to administer the system without relying as much on superusers,
which will allow us to safely ignore some of the weirdness caused by
superusers issuing grants.

Regards,
	Jeff Davis

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