Re: [PATCH v2] use has_privs_for_role for predefined roles

From: Joe Conway <mail(at)joeconway(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH v2] use has_privs_for_role for predefined roles
Date: 2022-02-09 00:38:22
Message-ID: 0b1b6cfb-d752-28f6-7ccb-993998be0189@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/8/22 10:07, Robert Haas wrote:
> On Tue, Feb 8, 2022 at 10:00 AM Joshua Brindle
> <joshua(dot)brindle(at)crunchydata(dot)com> wrote:
>> 4 predefined roles currently use has_privs_of_role in master.
>>
>> Further, pg_monitor, as an SQL-only predefined role, also behaves
>> consistently with the INHERIT rules that other roles do.
>>
>> In order for SQL-only predefined roles to ignore INHERIT we would need
>> to hardcode bypasses for them, which IMO seems like the worst possible
>> solution to the current inconsistency.
>
> I agree we need to make the situation consistent. But if you think
> there's exactly one problem here and this patch fixes it, I
> emphatically disagree.

If we were to start all over again with this feature my vote would be to
do things differently than we have done. I would not have called them
predefined roles, and I would have used attributes of roles (e.g. make
rolsuper into a bitmap rather than a boolean) rather than role
membership to implement them. But I didn't find time to participate in
the original discussion or review/write the code, so I have little room
to complain.

However since we did call these things predefined roles, and used role
membership to implement them, I think they ought to behave both
self-consistently as a group, and like other real roles.

That is what this patch does unless I am missing something.

I guess an alternative is to discuss a "proper fix", but it seems to me
that would be a version 16 thing given how late we are in this
development cycle and how invasive it is likely to be. And doing nothing
for pg15 is not a very satisfying proposition :-/

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-02-09 00:43:47 Re: pgsql: Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURR
Previous Message r.takahashi_2@fujitsu.com 2022-02-09 00:19:03 RE: Support escape sequence for cluster_name in postgres_fdw.application_name