Re: REVOKE's CASCADE protection doesn't work with INHERITed table owners

[moving to -hackers]

On Wed, Jun 24, 2026 at 2:57 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)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