Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE - Mailing list pgsql-general

From David G. Johnston
Subject Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
Date
Msg-id CAKFQuwYdD-rUZy7nYCi0K-RxvL-=s1wMHU6hqdBNY7VsaCwv3A@mail.gmail.com
Whole thread Raw
In response to Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
List pgsql-general
On Mon, Jul 8, 2024 at 2:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Luzanov <p.luzanov@postgrespro.ru> writes:
> On 08.07.2024 22:22, Christophe Pettus wrote:
>> This is more curiosity than anything else.  In the v16 role system, is there actually any reason to grant membership in a role to a different role, but with SET FALSE, INHERIT FALSE, and ADMIN FALSE?  Does the role granted membership gain any ability it didn't have before in that case?

> Looks like there is one ability.
> Authentication in pg_hba.conf "USER" field via +role syntax.

Hmm, if that check doesn't require INHERIT TRUE I'd say it's
a bug.


The code doesn't support that claim.  It seems quite intentional that this check is purely on membership - what with ACL having a dedicated function for the purpose of checking plain recursive membership that only this and the circularity check code use.  I suppose it makes sense too - at least unless you also check for SET - since it seems desirable to allow login as a member role to a group you can only SET to and don't inherit from.

David J.

pgsql-general by date:

Previous
From: Pavel Luzanov
Date:
Subject: Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
Next
From: Tom Lane
Date:
Subject: Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE