"David G. Johnston" <david.g.johnston@gmail.com> writes: > 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.
That doesn't make it not a bug.
Fair, the code was from a time when membership implied SET permission which apparently was, IMO, still is, a sufficient reason to allow a member of that group to login.
By making SET optional we removed this presumption and broke this code and now need to decide what is a valid setup to allow logging in. So, yes, a bug.
So long as we document that being a member of a group grants you the right to login if that group is named in pg_hba.conf I don't see how that is an invalid specification. It also isn't self-evidently correct. If we do agree that the status quo is undesirable the change I'd expect is to require at least one of the membership options to be true in order to be allowed to login.
But as we documented that membership is the only determinant here, by design or happenstance, we are behaving exactly as our documentation says.
As we are talking about logging in I'd be fine with potential breakage and implementing the "At least one" requirement. I wish we could break even allowing all-false as an active state but that seems too late to try and do. Better just to truly make it pointless and thus let there be no surprises.
