public inbox for [email protected]
help / color / mirror / Atom feedRe: set role command
2+ messages / 2 participants
[nested] [flat]
* Re: set role command
@ 2025-11-24 17:05 Álvaro Herrera <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Álvaro Herrera @ 2025-11-24 17:05 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Calvin Guo <[email protected]>; [email protected]
On 2025-Nov-24, Tom Lane wrote:
> Laurenz Albe <[email protected]> writes:
> > On Mon, 2025-11-24 at 16:15 +0800, Calvin Guo wrote:
> > I respect your feelings, but that is not how SET ROLE works.
> > The current behavior is intentional and documented in
> > https://www.postgresql.org/docs/current/sql-set-role.html
>
> And it's also required by the SQL standard, which is very clear
> that "user identifier" and "role" are different things, and
> SET ROLE only changes the latter.
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. 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.
Section 4.42 "Basic security model" of the 2023 edition of the standard
explains this. There is a stack of authorizations -- but when you do
SET SESSION AUTHORIZATION, you don't add another cell of the stack.
Instead, the current session user is replaced. They provide no way to
return. The stack is used for
<routine invocation>,
<externally-invoked procedure>,
triggered action,
<execute statement>, or
<direct SQL statement>
and the stack cell so created is automatically removed when that
operation completes.
Of course, I may be misreading the standard.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"No renuncies a nada. No te aferres a nada."
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: set role command
@ 2025-11-24 18:43 Tom Lane <[email protected]>
parent: Álvaro Herrera <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2025-11-24 18:43 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Calvin Guo <[email protected]>; [email protected]
=?utf-8?Q?=C3=81lvaro?= Herrera <[email protected]> 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?
> 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?". Since those
permissions are implementation-defined, I don't think it's possible
to argue that our choice breaks standards compliance. You can argue
that it's a bad idea, but it's a bit late to change it now.
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.
That'd allow sharing the same connection across different user IDs,
which isn't safe today.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-11-24 18:43 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-11-24 17:05 Re: set role command Álvaro Herrera <[email protected]>
2025-11-24 18:43 ` Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox