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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: cca5507 <cca5507(at)qq(dot)com>
Cc: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, preTham <prezza672(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Why is_admin_of_role() use ROLERECURSE_MEMBERS rather than ROLERECURSE_PRIVS?
Date: 2026-08-07 21:36:20
Message-ID: anZP1J0Y9pzHzMQC@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 07, 2026 at 12:04:44PM +0800, cca5507 wrote:
> The bot doesn't have privs of user1 by default, but is admin of user1. Changing
> is_admin_of_role() to use ROLERECURSE_PRIVS only affects the case of indirect
> inheritance. Do I miss something?

I think that's right. roles_is_member_of() sets *admin_role before
checking inheritance:

if (otherid == admin_of && form->admin_option &&
OidIsValid(admin_of) && !OidIsValid(*admin_role))
*admin_role = memberid;

So direct membership with admin but without inherit/set still allows you to
administrate the role.

At all rates, I think I'm inclined to proceed with something like v4. That
fixes the error message without changing any other behavior, which is
probably about the best we can do on the back-branches. Perhaps we should
consider changing is_admin_of_role() to use ROLERECURSE_PRIVS in v20, but I
don't sense much appetite for that, so... maybe we leave that thread loose
for now.

If nobody objects, I'll take care of committing/back-patching, hopefully in
the near future.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-08-07 22:00:43 Remove unused vacuum-truncate-auto injection point
Previous Message Christoph Berg 2026-08-07 20:27:04 Re: WAL compression setting after PostgreSQL LZ4 default change