On 1/2/24 08:21, Dominique Devienne wrote:
> On Tue, Jan 2, 2024 at 5:11 PM David G. Johnston
> <david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com>> wrote:
>
> On Tue, Jan 2, 2024 at 8:25 AM Dominique Devienne
> <ddevienne@gmail.com <mailto:ddevienne@gmail.com>> wrote:
>
> pg_has_role() from
> https://www.postgresql.org/docs/current/functions-info.html
> <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.
If you want the rationale see:
https://rhaas.blogspot.com/2023/01/surviving-without-superuser-coming-to.html
>
> Thanks, --DD
--
Adrian Klaver
adrian.klaver@aklaver.com