Re: SET ROLE x NO RESET

From: Michał Kłeczek <michal(at)kleczek(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Eric Hanson <eric(at)aquameta(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SET ROLE x NO RESET
Date: 2024-01-02 22:23:23
Message-ID: 894C0144-5BCC-41CB-A298-0C676D2D1C77@kleczek.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 2 Jan 2024, at 18:36, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Sun, Dec 31, 2023 at 2:20 PM Joe Conway <mail(at)joeconway(dot)com> wrote:
>> On 12/30/23 17:19, Michał Kłeczek wrote:
>>>> On 30 Dec 2023, at 17:16, Eric Hanson <eric(at)aquameta(dot)com> wrote:
>>>>
>>>> What do you think of adding a NO RESET option to the SET ROLE command?
>>>
>>> What I proposed some time ago is SET ROLE … GUARDED BY ‘password’, so
>>> that you could later: RESET ROLE WITH ‘password'
>>
>> I like that too, but see it as a separate feature. FWIW that is also
>> supported by the set_user extension referenced elsewhere on this thread.
>
> IMHO, the best solution here would be a protocol message to change the
> session user. The pooler could use that repeatedly on the same
> session, but refuse to propagate such messages from client
> connections.

I think that is a different use case and both are needed.

In my case I have scripts that I want to execute with limited privileges
and make sure the scripts cannot escape the sandbox via RESET ROLE.

Thanks,
Michal

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-01-02 22:49:07 Re: introduce dynamic shared memory registry
Previous Message Nathan Bossart 2024-01-02 22:00:18 Re: add AVX2 support to simd.h