Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sQx1W-00CUf1-Ms for pgsql-general@arkaria.postgresql.org; Mon, 08 Jul 2024 22:39:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sQx1U-00AEXo-VD for pgsql-general@arkaria.postgresql.org; Mon, 08 Jul 2024 22:39:52 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sQx1U-00AEXf-Fb for pgsql-general@lists.postgresql.org; Mon, 08 Jul 2024 22:39:52 +0000 Received: from mail-oo1-xc32.google.com ([2607:f8b0:4864:20::c32]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sQx1R-0016Vk-NR for pgsql-general@postgresql.org; Mon, 08 Jul 2024 22:39:51 +0000 Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-5c66ffadb7aso980175eaf.1 for ; Mon, 08 Jul 2024 15:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720478389; x=1721083189; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/RG8mhYeSnP1LZdyaFK1fh/zry0ZLNPzezbCdJnN/w8=; b=VI8QhLhFN9T2MipFe0GU+mD1/pL2+/Ie6e/SzmCk+/m108dcUftgR+D5UgOO8+0NuF 227UK0y/6AbBGvoZNr7wtN7R6KXUFGEtqN7Dy4WvUzGsl/qd9WrmkqHp4DI8nh3L92dL DM0cL1ePqYxE5LU6Wht11v/V9GvN3cDTpGoxsqycFarEasKneVn25+ym2e9wWF7B2UW9 bhQH/z1drQtAXNm3GSXHMjJ4a2KtaCZS+RcZZc1PsiGYuD5hr5zCEstVygOQWsE9+G24 WPf+1SOASjNXV6EZjWHhxnCt97ohtdi4NaCPBwHVXAeYsDxBVtN1SMF1M2pbBz7u9sRd nVCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720478389; x=1721083189; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/RG8mhYeSnP1LZdyaFK1fh/zry0ZLNPzezbCdJnN/w8=; b=lCMXv+26i5rStMp8P3bN6dx8YxXPg8g1fwGemJDNzMGOHgchlfRMyKityGCQjYkpha h0ukZu76u01/srlkokglly5nJmTc/rljbQTreouwPrFbZnSuZ2IZgRcqf3ttv2BDLSCK qETIQZhzipulJocr54DVpgC9b5zftAm531SFhf0NJRIsJ5l4OoGkfAYxkTCkxiNqoDC0 CBwabo6Gy+vje5qfXvom00OuUZ13vRZqQvaKUCy12POrjJ2OX6JO1dSozI6d92edcKNa E7at1ei8c9I9afx+8Q0asBtLjZXmnoraha4a6VIbskghn3FbDsOqQYZQDaSye9NDssar Tz1Q== X-Forwarded-Encrypted: i=1; AJvYcCWa0LW5qdWbhb2Aowq9bdtnIAdismK8PWtEa1ruZP3ac4Ghq5xFKaUGcb16eUK8Ov4D4OHLtZ9dyuiXVNBI5Z0FNfXHdtk9CGAwaX1A X-Gm-Message-State: AOJu0YycJGQ3zFBWFqdlsMhGSgOrhJpFTc75C1x55AUnQdgl4g0OUg9N ynpWrcSUh12B9hNCV3ruWimisbRexvzKAHLGkqOM+03LOu4b5heE3dyEo6x9312sgS7uZjoY/oe /j2tVpeEOTGgPPoQtL9wjKL6P3Ow= X-Google-Smtp-Source: AGHT+IHhS98vRIlvz6Qs7LDCufptTVydH8PyoMSDYKm2okUG1IUKgEX8uru1JnCu2uOrh874ikbE521PGJtNUu4tgms= X-Received: by 2002:a05:6870:70a4:b0:258:df79:291d with SMTP id 586e51a60fabf-25eae7ce011mr631747fac.5.1720478388852; Mon, 08 Jul 2024 15:39:48 -0700 (PDT) MIME-Version: 1.0 References: <69A2A7BD-F8CA-4067-B229-B5F9FC6A884F@thebuild.com> <2e3e4ddb-52b5-49b2-b363-00e3f12a83a0@postgrespro.ru> <1214992.1720473388@sss.pgh.pa.us> <1221566.1720476530@sss.pgh.pa.us> In-Reply-To: <1221566.1720476530@sss.pgh.pa.us> From: "David G. Johnston" Date: Mon, 8 Jul 2024 15:39:11 -0700 Message-ID: Subject: Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE To: Tom Lane Cc: Robert Haas , Pavel Luzanov , Christophe Pettus , pgsql-general Content-Type: multipart/alternative; boundary="000000000000361e5b061cc41724" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000361e5b061cc41724 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 8, 2024 at 3:08=E2=80=AFPM Tom Lane wrote: > "David G. Johnston" writes: > > On Mon, Jul 8, 2024 at 2:16=E2=80=AFPM Tom Lane wro= te: > >> Pavel Luzanov 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 differe= nt > >>>> 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. --000000000000361e5b061cc41724 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2024 at 3:08=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> = wrote:
"David G. Johnston" <david.g.johnston@g= mail.com> writes:
> On Mon, Jul 8, 2024 at 2:16=E2=80=AFPM 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.=C2=A0 In the v1= 6 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?= =C2=A0 Does the role
>>>> granted membership gain any ability it didn't have bef= ore 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 appa= rently was, IMO, still is, a sufficient reason to allow a member of that gr= oup to login.

By making SET optional we removed this p= resumption and broke this code and now need to decide what is a valid setup= to allow logging in.=C2=A0 So, yes, a bug.

So long as= we document that being a member of a group grants you the right to login i= f that group is named in pg_hba.conf I don't see how that is an invalid= specification.=C2=A0 It also isn't self-evidently correct.=C2=A0 If we= do agree that the status quo is undesirable the change I'd expect is t= o 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,=C2=A0we are behav= ing exactly as our documentation says.

As we are talki= ng about logging in I'd be fine with potential breakage and implementin= g the "At least one" requirement.=C2=A0 I wish we could break eve= n allowing all-false as an active state but that seems too late to try and = do.=C2=A0 Better just to truly make it pointless and thus let there be no s= urprises.

David J.
--000000000000361e5b061cc41724--