On Thu, Sep 12, 2024 at 3:40 PM Dominique Devienne <ddevienne@xxxxxxxxx> wrote:
>
> 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...
>
So I guess I would respectfully disagree with
the idea that this works on v14 and v16 broke it. It doesn't really
work on v14, or at least not any better than just using SUPERUSER
everywhere that you're currently using CREATEROLE. And if you choose
to do that, I think your example will work pretty much the same way on
v16 as it does on v14.
After false-starting on a few replies and pondering a bit more that is basically what I’ve come to conclude as well. We basically changed things because this model was deemed dangerous. I suppose we took little effort to make it safer in the new regime had anyone decided to use it anyway, instead figuring that most would separate the main DAG of application roles from the object owners and role creators. At least that’s always been my base design principle.
However, it seems like we might be able to fix this by just making the
code smarter. Maybe there's a problem that I'm not seeing, but if the
boss grants a privilege to alice and alice grants it to bob and bob
grants it back to alice and then the boss revokes the privilege, why
can't we figure out that alice no longer has a source for that
privilege *aside from the one involved in the cycle* and undo the
reciprocal grants that bob and alice made to each other? Right now I
believe we just ask "is the number of sources that alices has for this
privilege still greater than zero" which only works if there are no
cycles but maybe we can do better. We'd probably need to think
carefully about concurrency issues, though, and whether pg_dump is
smart enough to handle this case. Also, there are separate code paths
for role grants and non-role grants, and since I went to a lot of
trouble to make them work the same way, I'd really prefer it if we
didn't go back to having them work differently...
I’m definitely not keen on trying to deal with circularities in the graph. I get that we broke a working model here but I’m still not seeing why that model is one we would strive to accommodate in a green-field situation.
A user can delegate away some ability to a role they create but cannot make it so roles they create can pretend to be their creator. The main thing I haven’t looked into is if alice delegates createrole to bob and then removes bob does she assume all of the roles bob created or must there be an explicit reassigned owned executed?
David J.
