Re: New SET privilege for pg_has_role() in v16+ - Mailing list pgsql-general

From Dominique Devienne
Subject Re: New SET privilege for pg_has_role() in v16+
Date
Msg-id CAFCRh-9fwuiO=T_ddbsF2gPwunPdMDf1pi=Vveo9OPD0FvA5Zw@mail.gmail.com
Whole thread Raw
In response to Re: New SET privilege for pg_has_role() in v16+  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: New SET privilege for pg_has_role() in v16+  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: New SET privilege for pg_has_role() in v16+  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
On Tue, Jan 2, 2024 at 5:11 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Tue, Jan 2, 2024 at 8:25 AM Dominique Devienne <ddevienne@gmail.com> wrote:
pg_has_role() from https://www.postgresql.org/docs/current/functions-info.html
added the 'SET' privilege in v16, and on top of the existing 'MEMBER' and 'USAGE' ones:
 
Membership no longer does anything by itself.

OK! That's news to me, I must go back to the v16 (?) release notes and learn more about this.
 
Both inherit and set capabilities are now individually controlled permissions related to membership.

Hmmm, what drove this change? (I guess I'm getting back to the rationale from earlier).
The previous model was not granular enough?
And the new one is as granular as it gets?

It is indeed possible, but not useful, to grant membership but then disallow both set and inherit permissions.

OK. Yet another thing I'll need to study.

As I wrote earlier, we use ROLEs extensively, some INHERIT and others NOT INHERIT,
to map an existing C/C++ enforce security model in mid-tier services, to a ROLE/GRANT-based
one enforced by PostgreSQL itself, thus understanding why these changes were made in v16 matters to me a lot.

Thanks, --DD

pgsql-general by date:

Previous
From: Dominique Devienne
Date:
Subject: Re: New SET privilege for pg_has_role() in v16+
Next
From: "David G. Johnston"
Date:
Subject: Re: New SET privilege for pg_has_role() in v16+