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

From Stephen Frost
Subject Re: role self-revocation
Date
Msg-id CAOuzzgqDRVTs3vYr2Z-pjveXXcmGa7V5NwCFFLnJEcQE8ujBdg@mail.gmail.com
Whole thread Raw
In response to Re: role self-revocation  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: role self-revocation  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
Greetings,

On Fri, Mar 11, 2022 at 19:03 Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> On Mar 11, 2022, at 2:46 PM, Stephen Frost <sfrost@snowman.net> wrote:
>
> I do think that’s reasonable … and believe I suggested it about 3 messages ago in this thread. ;)  (step #3 I think it was?  Or maybe 4).

Yes, and you mentioned it to me off-list.

Indeed.

I'm soliciting a more concrete specification for what you are proposing.  To me, that means understanding how the SQL spec behavior that you champion translates into specific changes.  You specified some of this in steps #1 through #5, but I'd like a clearer indication of how many of those (#1 alone, both #1 and #2, or what?) constitute a competing idea to the idea of role ownership, and greater detail about how each of those steps translate into specific behavior changes in postgres.  Your initial five-step email seems to be claiming that #1 by itself is competitive, but to me it seems at least #1 and #2 would be required.

First … I outlined a fair bit of further description in the message you just responded to but neglected to include in your response, which strikes me as odd that you’re now asking for further explanation.  When it comes to completing the idea of role ownership- I didn’t come up with that idea nor champion it and therefore I’m not really sure how many of the steps are required to fully support that concept..?  For my part, I would think that those steps necessary to satisfy the spec would get us pretty darn close to what true folks advocating for role ownership are asking for, but that doesn’t include the superuser-only alter role attributes piece.  Is that included in role ownership?  I wouldn’t think so, but some might argue otherwise, and I don’t know that it is actually useful to divert into a discussion about what is or isn’t in that.

If we agree that the role attribute bits are independent then I think I agree that we need 1 and 2 to get the capabilities that the folks asking for role ownership want, as 2 is where we make sure that one admin of a role can’t revoke another admin’s rights over that role.  Perhaps 2 isn’t strictly necessary in a carefully managed environment where no one else is given admin rights over the mini-superuser roles, but I’d rather not have folks depending on that.  I’d still push back though and ask those advocating for this if it meets what they’re asking for.  I got the impression that it did but maybe I misunderstood.

In terms of exactly how things would work with these changes… I thought I explained it pretty clearly, so it’s kind of hard to answer that further without a specific question to answer.  Did you have something specific in mind?  Perhaps I could answer a specific question and provide more clarity that way.

Thanks,

Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Kerberos delegation support in libpq and postgres_fdw
Next
From: David Zhang
Date:
Subject: Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit