Re: role self-revocation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: role self-revocation
Date: 2022-03-10 17:11:36
Message-ID: CA+TgmoaNX4JaDymfZAv0V_UEvgzcMpeFStD4LyTdoOR_upkAjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 10, 2022 at 11:19 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I disagree that ownership is needed that's not what the spec calls for
> either. What we need is more flexibility when it comes to the
> relationships which are allowed to be created between roles and what
> privileges come with them. To that end, I'd argue that we should be
> extending pg_auth_members, first by separating out membership itself
> into an explicitly tracked attribute (instead of being implicit in the
> existance of a row in the table) and then adding on what other
> privileges we see fit to add, such as the ability to DROP a role. We
> do need to remove the ability for a role who hasn't been explicitly
> given the admin right on another role to modify that role's membership
> too, as was originally proposed here. This also seems to more closely
> follow the spec's expectation, something that role ownership doesn't.

I do not have a problem with more fine-grained kinds of authorization
even though I think there are syntactic issues to work out, but I
strongly disagree with the idea that we can't or shouldn't also have
role ownership. Marc invented it. Now Tom has invented it
independently. All sorts of other objects have it already. Trying to
make it out like this is some kind of kooky idea is not believable.
Yeah, it's not the most sophisticated or elegant model and that's why
it's good for us to also have other things, but for simple cases it is
easy to understand and works great.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-03-10 17:11:59 Re: pg_stat_statements and "IN" conditions
Previous Message Andrew Dunstan 2022-03-10 17:05:31 Re: ltree_gist indexes broken after pg_upgrade from 12 to 13