Re: role self-revocation

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: role self-revocation
Дата
Msg-id CAOuzzgqDRVTs3vYr2Z-pjveXXcmGa7V5NwCFFLnJEcQE8ujBdg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: role self-revocation  (Mark Dilger <mark.dilger@enterprisedb.com>)
Ответы Re: role self-revocation  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Kerberos delegation support in libpq and postgres_fdw
Следующее
От: David Zhang
Дата:
Сообщение: Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit