Re: New SET privilege for pg_has_role() in v16+

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