On Thu, Sep 12, 2024 at 2:40 PM Dominique Devienne <ddevienne@xxxxxxxxx> wrote: > Basically the above explain why we have that > dd_user (INHERIT) > `-> member-of dd_admin (NOINHERIT) > `-> member-of dd_owner (INHERIT). > > In pre-v16, once again, this was fine. > Because v16+ adds that dd_owner member-of dd_user (ADMIN) > edge, things break down. Another way to look at it is this: === v14 === ddevienne=> create role dd_child; CREATE ROLE ddevienne=> select pg_has_role(current_role, 'dd_child', 'MEMBER'); pg_has_role ------------- f (1 row) === v16 === ddevienne=> create role dd_child; CREATE ROLE ddevienne=> select pg_has_role(current_role, 'dd_child', 'MEMBER'); pg_has_role ------------- t (1 row) Any existing ROLE graph which had "back-edges" (GRANTs) from a ROLE back to the ROLE that created it, valid in pre-v16, becomes invalid in v16+. And there's no work-around. Tough luck, take a hike... And our security model and its implementation basically requires such back-edges. My contention is that if this is an ADMIN-only edge, it shouldn't be deemed circular. Kind of the same way you break cycles in FKs by making one side DEFERRED, ADMIN edges should be "weaker" than SET ones, and break cycles. Maybe I'm the only one in the world using PostgreSQL in that situation? Somehow I doubt that. Most people and organization are slow to upgrade, and v16 is new enough that it wasn't exposed to enough real world usage yet. So this is issue is only get bigger as time passes IMHO. Thanks, --DD
