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

> On Mar 11, 2022, at 4:56 PM, Stephen Frost <sfrost@snowman.net> wrote:
>
> First … I outlined a fair bit of further description in the message you just responded to but neglected to include in
yourresponse, 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,
asI 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
sameproblems, 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
truefolks 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
needingsuperuser 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’tthink so, but some might argue otherwise, and I don’t know that it is actually useful to divert into a
discussionabout 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
CREATEROLEis also fixed.  There isn't any point having non-superusers create and own roles if, to do so, they need a
privilegewhich can break into superuser.  But that argument is no different with a patch along the lines of what you
areproposing.  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
Ifind 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
themini-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
impressionthat 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
ofhard to answer that further without a specific question to answer.  Did you have something specific in mind?  Perhaps
Icould 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
thatisn't really necessary, and ...." which left me unclear on the proposal.  I don't mean to disparage your
communicationstyle; 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
elseto do so.  Thanks. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company