[moving to -hackers]
On Wed, Jun 24, 2026 at 2:57 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> TL;DR: The protection in recursive_revoke() against broken GRANT
> OPTION chains doesn't seem to work properly when the grantee also
> holds the privileges of the grantor.
More accurately: "when an intermediate grantor in the chain only
indirectly holds the ability to grant."
> I think the issue is in recursive_revoke()'s usage of aclmask(), which
> in turn uses has_privs_of_role(). It doesn't seem like that's what was
> wanted in this particular case... thoughts?
I propose changing that to aclmask_direct(), as in the attached, and
backpatching all the way down.
To try to prove to myself that this works, I added tests to pin each
of the three cases that are treated differently by aclmask_direct():
1. the grantor has indirect ownership privileges
2. the grantor has indirect grant options via INHERIT
3. the grantor has indirect grant options via PUBLIC (which is already
disallowed in practice)
I also tried to expand the existing comment, both to point out the
pitfall and to explain why the short-circuit works. But I've rewritten
it at least a dozen times, so if anyone can tell me whether I've made
sense and/or used the terminology appropriately, I'd appreciate it.
> I'm pretty sure the following is unintended behavior. It looks
> potentially related to [1] as well.
(To fix [1] I suspect we need to make a similar tweak to
check_circularity(), but I haven't looked into that yet.)
Thanks!
--Jacob
[1] https://postgr.es/m/CAM6Zo8wD7RtQNhbQHODc9DobiW+GpT=tnqOSMz4+mnzA9m0zMg@mail.gmail.com
