Thread

  1. Re: Why is_admin_of_role() use ROLERECURSE_MEMBERS rather than ROLERECURSE_PRIVS?

    Nathan Bossart <nathandbossart@gmail.com> — 2026-05-06T16:48:27Z

    On Wed, Apr 29, 2026 at 04:46:05PM +0800, cca5507 wrote:
    >> I'm pretty strongly disinclined to change the meaning of
    >> is_admin_of_role() in released code. That affects more than this call
    >> site. When this code was under development, one of the use cases that
    >> was booted was a user management bot who should be able to run ALTER
    >> ROLE but should not automatically exercise the privilege of any
    >> created roles. If we standardize on ROLERECURSE_PRIVS, that use case
    >> doesn't work any more. You now have to inherit a role's privileges or
    >> AlterRole() will fail.
    > 
    > This use case makes sense to me.
    > 
    >> One idea could be that non-membership changes to roles continue to
    >> work as they do today, but membership changes use ROLERECURSE_PRIVS.
    >> So we'd have is_admin_of_role() and inherits_admin_privs_for_role()
    >> and be careful to use the right one in each case. This seems a little
    >> weird, but I'm not sure what would be better.
    > 
    > Attach a patch done like this.
    
    The patch seems to resolve the reported case.  I don't like how the new
    function is named "has_admin_option_on_role()" because it sounds like it
    means the exact same thing as "is_admin_of_role()".  IMHO Robert's
    suggestion of inherits_admin_privs_of_role() would be better.
    
    I don't have any better ideas for how to solve it, but I also fear for the
    day when I have to explain these subtle differences in behavior to a casual
    user...
    
    -- 
    nathan