Re: set role command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Calvin Guo <newoakllc2023(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: set role command
Date: 2025-11-24 16:18:20
Message-ID: 955750.1764001100@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Mon, 2025-11-24 at 16:15 +0800, Calvin Guo wrote:
>> I really feel, once you "set role usera", you should behave like usera, you should
>> NOT have the power say: hi, I can assume my super user power whenever I want.
>> As this make the "set role usera" pretty much useless.

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

> There is SET SESSION AUTHORIZATION, which acts somewhet more like you want,
> except that you can become a superuser again with RESET SESSION AUTHORIZATION.

In the standard, the privileges required to do SET SESSION
AUTHORIZATION are "implementation defined", which means we could
change how it works without breaking standards conformance.
We'd still be breaking backwards compatibility, though --- for
instance, pg_dump dumps made with --use-set-session-authorization
would stop working. I think that a proposal to change this has
very little chance of succeeding.

The best way to lock things down is to start a new session under
the restricted user name.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Álvaro Herrera 2025-11-24 17:05:50 Re: set role command
Previous Message immerrr again 2025-11-24 15:59:14 DROP ROLE blocked by pg_init_privs