[moving to -hackers] On Wed, Jun 24, 2026 at 2:57 PM Jacob Champion <[email protected]> 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+mnza9m0...@mail.gmail.com
v1-0001-Prevent-broken-grant-chains-when-indirect-grant-o.patch
Description: Binary data
