Re: role self-revocation - Mailing list pgsql-hackers

On Thu, Mar 10, 2022 at 5:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This seems reasonable in isolation, but
>
> (1) it implies a persistent relationship between creating and created
> roles.  Whether you want to call that ownership or not, it sure walks
> and quacks like ownership.

I agree. It's been obvious to me from the beginning that we needed
such a persistent relationship, and also that it needed to be a
relationship from which the created role couldn't simply walk away.
Yet, more than six months after the first discussions of this topic,
we still don't have any kind of agreement on what that thing should be
called. I like my TENANT idea best, but I'm perfectly willing to call
it ownership as you seem to prefer or WITH ADMIN OPTION as Stephen
seems to prefer if one of those ideas gains consensus. But we've
managed to waste all hope of making any significant progress here for
an entire release cycle for lack of ability to agree on spelling. I
think that's unfair to Mark, who put a lot of work into this area and
got nothing out of it, and I think it sucks for users of PostgreSQL,
too.

> (2) it seems exactly contradictory to your later point that
>
> > Agree. I also think that it would be a good idea to attribute grants
> > performed by any superuser to the bootstrap superuser, or leave them
> > unattributed somehow. Because otherwise dropping superusers becomes a
> > pain in the tail for no good reason.
>
> Either there's a persistent relationship or there's not.  I don't
> think it's sensible to treat superusers differently here.
>
> I think that this argument about the difficulty of dropping superusers
> may in fact be the motivation for the existing behavior that object-
> permissions GRANTs done by superusers are attributed to the object
> owner; something you were unhappy about upthread.
>
> In the end these requirements seem mutually contradictory.  Either
> we can have a persistent ownership relationship or not, but I don't
> think we can have it apply in some cases and not others without
> creating worse problems than we solve.  I'm inclined to toss overboard
> the requirement that superusers need to be an easy thing to drop.
> Why is that important, anyway?

Well, I think you're looking at it the wrong way. Compared to getting
useful functionality, the relative ease of dropping users is
completely unimportant. I'm happy to surrender it in exchange for
something else. I just don't see why we should give it up for nothing.
If Alice creates non-superusers Bob and Charlie, and Charlie creates
Doug, we need the persistent relationship to know that Charlie is
allowed to drop Doug and Bob is not. But if Charlie is a superuser
anyway, then the persistent relationship is of no use. I don't see the
point of cluttering up the system with such dependencies. Will I do it
that way, if that's what it takes to get the patch accepted? Sure. But
I can't imagine any end-user actually liking it.

> I'm a bit disturbed that parts of this discussion seem to be getting
> conducted with little understanding of the system's existing behaviors.
> We should not be reinventing things we already have perfectly good
> solutions for in the object-privileges domain.

I did wonder whether that might be the existing behavior, but stopping
to check right at that moment didn't seem that important to me. Maybe
I should have taken the time, but it's not like we're writing the
final patch for commit next Tuesday at this point. It's more important
at this point to get agreement on the principles. That said, I do
agree that there have been times when we haven't thought hard enough
about the existing behavior in proposing new behavior. On the third
hand, though, part of the problem here is that neither Stephen nor I
are entirely happy with the existing behavior, if for somewhat
different reasons. It really isn't "perfectly good." On the one hand,
from a purely technical standpoint, a lot of the behavior around roles
in particular seems well below the standard that anyone would consider
committable today. On the other hand, even the parts of the code that
are in reasonable shape from a code quality point of view don't
actually do the things that we think users want done.

-- 
Robert Haas
EDB: http://www.enterprisedb.com