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.96) (envelope-from ) id 1vNd8a-009Afs-0Y for pgsql-general@arkaria.postgresql.org; Mon, 24 Nov 2025 20:26:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vNd8Y-0043oH-2L for pgsql-general@arkaria.postgresql.org; Mon, 24 Nov 2025 20:26:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vNd8Y-0043nT-1E for pgsql-general@lists.postgresql.org; Mon, 24 Nov 2025 20:26:14 +0000 Received: from mail-oo1-xc2b.google.com ([2607:f8b0:4864:20::c2b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vNd8T-001IAq-23 for pgsql-general@lists.postgresql.org; Mon, 24 Nov 2025 20:26:14 +0000 Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-656b612e607so2216996eaf.2 for ; Mon, 24 Nov 2025 12:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764015966; x=1764620766; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=j/22Dyf2hwoFKAGCFiuvOHir7Q/8Czrd+Uf2Cz9DdGQ=; b=HnWd//nW6Nz2G7Hf+LoM7OfFbYdh6+dpJAhEy3ep4VjiilE8KM7R91iComlFG9q9nb BnABqKr3Mwsv7Vj0FWO/BUwg17mXOh3GBQbHOUVWLxWK1I33uFGnjuXdp0ReJ9incbiQ xyIIFGl+vYnyofWP5aQteeIo9uM3Uxe63A8HJ6oqcitd+6YNodamgmYts8u4pzWjcvLI QeHb+McY94QAxfgAOf6dQlMkzO5zaKT++tJzoaRdIOG5LfIMzg9aEJR1O7jOxAT7RWpg hZZwKvSZwQ7U7WTSdX86WAKkWJo0HA3BT1ps1Toa4U3uHNYnDYTTaAtAPdgRZE2rHLol gyaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764015966; x=1764620766; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j/22Dyf2hwoFKAGCFiuvOHir7Q/8Czrd+Uf2Cz9DdGQ=; b=TKuyQS6v2Rqba5Yqa6DAWFWOWYArolz5upsbgQKP+GBH/jJ0lCgWaUETnkHeF9Z30z 2XS0dTesFqWAWdnbeCc+UyntYGK4IWMTcRq0khI6IkDJC1X32cnrEXYH4z+GGHNbgwDd jaGOAmqltr2Ky30JLD3nJE6Kkgu48/WyTBYS7BY6fOv5QZAzdX1rIjz76DIeG+zPc1W+ K2g9OsmrgNdeJAvly5e81e3T0zhn7eTxMl8bA9nu7UGXs+tXZs6uRhdwTXiP654fAGqx Q0/PIt+kgIbu+ToPDFHX3su/c4RiaHQGTkcYQiEAEf+f5ixGF8tVfV54ZPKGu/ZKIgOE a9HQ== X-Gm-Message-State: AOJu0Yw1RueHNsvAFDAwUOiJTR8RnbU3x3pRI6JBv++aBOfJC16xSmJR H8etrzgN2j7ALh7BiMwV0WyzFsgQ134hf83drfTONYyWrDY36xOJ6aqv4i9zRgY/5GY2TOZb3Ks 8SkVBNUTW8JzUGXaDVouXSHFfMPKRMcJlLQ== X-Gm-Gg: ASbGncugF7MeLCiKBBfnzo9UP1XPWANVjRWQABckBHEQVqKWdnlVjufpzf6RQfpPGUN 813SUf/14KhbRoPfGcB5IoVrDm6YAHrreCF6AeZ8xiYPUnTZTwpfQTxhTHXpp+eRM5IdTnduB3f YWlOtRGfWpyOKAcBcvBAhLdqmp7xy/adePhfi0mpaivWFht7f3C7oHjdFFJq1EvFm596PB/WDqK zrngRW9WAvcZV8MejvcyZHzO341L8YEdtex7JR2joMlcL1KJ4jFAs9sJoJQXPa7HyNFGSRn9QrG JOFBMmV6 X-Google-Smtp-Source: AGHT+IF3cIF2fdublErpN+8KXRZP1Owpge6nhaIYRKTPGcObpC9EigWxvvFFY4m1w3TV6brjmYsU6vunKZpRiDoOFg0= X-Received: by 2002:a05:6808:3086:b0:450:3124:53b7 with SMTP id 5614622812f47-45112d663damr6363206b6e.67.1764015966293; Mon, 24 Nov 2025 12:26:06 -0800 (PST) MIME-Version: 1.0 References: <202511241909.nudhcfkcugfl@alvherre.pgsql> <988533.1764013580@sss.pgh.pa.us> In-Reply-To: <988533.1764013580@sss.pgh.pa.us> From: Ron Johnson Date: Mon, 24 Nov 2025 15:25:53 -0500 X-Gm-Features: AWmQ_bnBAfqtu0cV52zekfFPnnX7DPmv6gXklNmwvkUXl86iRHgD38_LINEDx5Y Message-ID: Subject: Re: set role command To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="0000000000000c92c206445cf95b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000000c92c206445cf95b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 24, 2025 at 2:46=E2=80=AFPM Tom Lane wrote: > =3D?utf-8?Q?=3DC3=3D81lvaro?=3D Herrera writes: > > On 2025-Nov-24, Tom Lane wrote: > >> I don't think so. They are just shorthand for issuing a SET to the > >> original value, so how do they break the model in a way that that > >> doesn't? > > > No, because the new user doesn't have privs to become the previous one. > > Don't think you can make that argument from the standard, since > it explicitly disclaims saying what privs are required. > > > It would be more > > secure to have a mechanism where the connection is initially > > unauthenticated altogether (which means: it's not a valid SQL session), > > becomes authenticated at the pooler's will, and returns to > > unauthenticated state as the pooler decides. Critically, from > > unauthenticated state you shouldn't be able to become superuser. > > I don't like the idea that a pooler or pretend-to-be pooler > can eat up a backend session without having authenticated at all. > Also, exactly what does "becomes authenticated at the pooler's will" > mean? There had better be some actual authentication happening > somewhere. > A restriction that it can only happen when TLS authentication is used, and the pooler is using its service account? --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000000c92c206445cf95b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 24, 2025 at 2:46=E2=80=AFPM T= om Lane <tgl@sss.pgh.pa.us> = wrote:
=3D?utf-8?Q?=3DC3=3D81lvaro?=3D Herrera= <alvherre@kur= ilemu.de> writes:
> On 2025-Nov-24, Tom Lane wrote:
>> I don't think so.=C2=A0 They are just shorthand for issuing a = SET to the
>> original value, so how do they break the model in a way that that<= br> >> doesn't?

> No, because the new user doesn't have privs to become the previous= one.

Don't think you can make that argument from the standard, since
it explicitly disclaims saying what privs are required.

> It would be more
> secure to have a mechanism where the connection is initially
> unauthenticated altogether (which means: it's not a valid SQL sess= ion),
> becomes authenticated at the pooler's will, and returns to
> unauthenticated state as the pooler decides.=C2=A0 Critically, from > unauthenticated state you shouldn't be able to become superuser.
I don't like the idea that a pooler or pretend-to-be pooler
can eat up a backend session without having authenticated at all.
Also, exactly what does "becomes authenticated at the pooler's wil= l"
mean?=C2=A0 There had better be some actual authentication happening
somewhere.

A restriction that it can on= ly happen when TLS authentication is used, and the pooler is using its serv= ice account?

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'= ;m still alive.
<Redacted> lobster!
--0000000000000c92c206445cf95b--