Feedback-ID: ie3de48e3:Fastmail
Date: Mon, 24 Nov 2025 20:21:23 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, 
	Calvin Guo <newoakllc2023@gmail.com>, pgsql-general@lists.postgresql.org
Subject: Re: set role command
Message-ID: <202511241909.nudhcfkcugfl@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <981855.1764009811@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/202511241909.nudhcfkcugfl%40alvherre.pgsql>
Precedence: bulk

On 2025-Nov-24, Tom Lane wrote:

> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> > For what it's worth, I think we break the SQL standard's security model
> > by providing RESET ROLE and RESET SESSION AUTHORIZATION, neither of
> > which the standard has.
> 
> 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.

> > This means that in the standard model you have
> > commands to lower your privilege, but once you've lowered them, you
> > cannot return (in the same connection) to what you had.
> 
> The reason PG acts as it does is that we interpret "the permissions
> required to do SET SESSION AUTHORIZATION" as "did your originally
> authenticated ID have permission to do that SET?".

I have the impression that that's broken, because for <set session user
identifier statement>,  the standard says that the current user
identifier is set to the new user, which means the previous user
identifier is lost.  You don't retain rights to become that user again.

> In practical terms, the one-way changes that Calvin wants are just not
> that attractive.  What people have actually asked for, particularly
> connection-pooler authors, are a way to switch session authorization
> in such a way that you can only go back with some additional secret
> sauce, like a one-time password generated at the pooler level.

Yeah, I think connection poolers would be better served by a different
security model than what the standard offers.  The pooler-generated
one-time password, or something similar, seems somewhat appropriate
given what we offer today.  I'm not sure it's the best model either,
because it requires that the connection is initially in a superuser-like
state (so that it can become any other user).  But that's somewhat
dangerous, because if an attacker manages to steal the one-time
password, they are database superuser and all is lost.  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.

(Also, last I looked at pgbouncer, it had to do some weird tricks to
mimick the authentication on their side without involving the server, so
it wanted to keep its own list of user/passwords or something like that.
Maybe that's changed in the last few years though.)

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Having your biases confirmed independently is how scientific progress is
made, and hence made our great society what it is today" (Mary Gardiner)