Re: Why is_admin_of_role() use ROLERECURSE_MEMBERS rather thanROLERECURSE_PRIVS?

Added Robert to the thread.

Yeah, something doesn't seem right here. As mentioned upthread, the
following ERROR in check_role_grantor() is easily reached:

* Otherwise, the grantor must either have ADMIN OPTION on the role or
* inherit the privileges of a role which does. In the former case,
* record the grantor as the current user; in the latter, pick one of
* the roles that is "most directly" inherited by the current role
* (i.e. fewest "hops").
*
* (We shouldn't fail to find a best grantor, because we've already
* established that the current user has permission to perform the
* operation.)
*/
grantorId = select_best_admin(currentUserId, roleid);
if (!OidIsValid(grantorId))
elog(ERROR, "no possible grantors");

This was added by commit ce6b672e44, which first took effect in v16. IIUC
earlier versions simply check is_admin_of_role() and mark the grantor as
the current role, at least when adding members. I haven't found any other
e-mails or documentation about this.

Changing is_admin_of_role() to use ROLERECURSE_PRIVS would make things more
restrictive (e.g., the DROP ROLE in the test fails), which has the
potential to break existing scripts. But it does seem intuitive that if
you don't INHERIT a roles privileges, you don't inherit its ADMIN rights
either.

--
nathan