public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Álvaro Herrera <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: Calvin Guo <[email protected]>
Cc: [email protected]
Subject: Re: set role command
Date: Mon, 24 Nov 2025 14:46:20 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

=?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.

If we tried doing that, I'd prefer that the "rest state" be validly
authenticated, but it could be as a low-privilege user that can't
do much of anything.  However, then we'd need to have an actual
authentication exchange to raise privilege to whatever you wanted
to do useful work as, and that would have to be a protocol-level
thing not a SQL command.  I also wonder how much poolers would
really want to use that, because it'd partially defeat the goal
of quickly switching to different users.

			regards, tom lane

view thread (3+ 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: set role command
  In-Reply-To: <[email protected]>

* 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