On Mon, Nov 24, 2025 at 2:46 PM Tom Lane <[email protected]> wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera <[email protected]> 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!
