Re: set role command - Mailing list pgsql-general

From Tom Lane
Subject Re: set role command
Date
Msg-id 955750.1764001100@sss.pgh.pa.us
Whole thread Raw
In response to Re: set role command  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: set role command
Re: set role command
List pgsql-general
Laurenz Albe <laurenz.albe@cybertec.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



pgsql-general by date:

Previous
From: immerrr again
Date:
Subject: DROP ROLE blocked by pg_init_privs
Next
From: Álvaro Herrera
Date:
Subject: Re: set role command