Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, Christophe Pettus <xof(at)thebuild(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
Date: 2024-07-08 22:39:11
Message-ID: CAKFQuwbzgPyKMaohhE7xBhxy5VkXPHziy9AiD5ZHGOTg=XeNpw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jul 8, 2024 at 3:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Mon, Jul 8, 2024 at 2:16 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)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.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2024-07-08 22:58:00 Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
Previous Message Joseph Hammerman 2024-07-08 22:26:23 SQL: Chaining versus Pipelining