| From: | cca5507 <cca5507(at)qq(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | 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-04-29 08:46:05 |
| Message-ID: | tencent_F9FE41981D5EE851E14FAD4D8AA08C0F5E06@qq.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
--
Regards,
ChangAo Chen
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0001-Fix-error-no-possible-grantors.patch | application/octet-stream | 3.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2026-04-29 09:24:50 | Re: tuple radix sort |
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-04-29 08:40:21 | RE: [PATCH] Preserve replication origin OIDs in pg_upgrade |