public inbox for [email protected]  

help / color / mirror / Atom feed

From: David G. Johnston <[email protected]>
To: Tom Lane <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Pavel Luzanov <[email protected]>
Cc: Christophe Pettus <[email protected]>
Cc: pgsql-general <[email protected]>
Subject: Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
Date: Mon, 8 Jul 2024 15:39:11 -0700
Message-ID: <CAKFQuwbzgPyKMaohhE7xBhxy5VkXPHziy9AiD5ZHGOTg=XeNpw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAKFQuwYdD-rUZy7nYCi0K-RxvL-=s1wMHU6hqdBNY7VsaCwv3A@mail.gmail.com>
	<[email protected]>

On Mon, Jul 8, 2024 at 3:08 PM Tom Lane <[email protected]> wrote:

> "David G. Johnston" <[email protected]> writes:
> > On Mon, Jul 8, 2024 at 2:16 PM Tom Lane <[email protected]> wrote:
> >> Pavel Luzanov <[email protected]> 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.

view thread (5+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
  In-Reply-To: <CAKFQuwbzgPyKMaohhE7xBhxy5VkXPHziy9AiD5ZHGOTg=XeNpw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox