Re: set role command

On Mon, Nov 24, 2025 at 2:46 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre(at)kurilemu(dot)de> 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?

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