Re: Backward compat issue with v16 around ROLEs

On Thursday, September 12, 2024, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Sep 12, 2024 at 3:40 PM Dominique Devienne <ddevienne(at)gmail(dot)com>
> 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.