> On Mar 11, 2022, at 4:56 PM, Stephen Frost <sfr...@snowman.net> wrote:
>
> 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
Sorry, not "completing", but "competing". It seems we're discussing different
ways to fix how roles and CREATEROLE work, and we have several ideas competing
against each other. (This differs from *people* competing against each other,
as I don't necessarily like the patch I wrote better than I like your idea.)
> and therefore I’m not really sure how many of the steps are required to fully
> support that concept..?
There are problems that the ownership concepts solve. I strongly suspect that
your proposal could also solve those same problems, and just trying to identify
the specific portions of your proposal necessary to do so.
> 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
I have little idea what "true folks" means in this context. As for "advocating
for role ownership", I'm not in that group. Whether role ownership or
something else, I just want some solution to a set of problems, mostly to do
with needing superuser to do role management tasks.
> , 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.
Introducing the idea of role ownership doesn't fix that. But a patch which
introduces role ownership is useless unless CREATEROLE is also fixed. There
isn't any point having non-superusers create and own roles if, to do so, they
need a privilege which can break into superuser. But that argument is no
different with a patch along the lines of what you are proposing. CREATEROLE
needs fixing either way.
> If we agree that the role attribute bits are independent
Yes.
> then I think I agree that we need 1 and 2 to get the capabilities that the
> folks asking for role ownership want
Yes.
> as 2 is where we make sure that one admin of a role can’t revoke another
> admin’s rights over that role.
Exactly, so #2 is part of the competing proposal. (I get the sense you might
not see these as competing proposals, but I find that framing useful for
deciding which approach to pursue.)
> 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 think it is necessary, and for the reason you say.
> 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.
Your emails contained a lot of "we could do this or that depending on what
people want, and maybe this other thing, but that isn't really necessary, and
...." which left me unclear on the proposal. I don't mean to disparage your
communication style; it's just that when trying to distill technical details,
high level conversation can be hard to grok.
I have the sense that you aren't going to submit a patch, so I wanted this
thread to contain enough detail for somebody else to do so. Thanks.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
