On Sat, Dec 30, 2023 at 11:50 AM Joe Conway wrote:
> In the meantime, in case it helps, see
>
>https://github.com/pgaudit/set_user
>
> Specifically set_session_auth(text):
> -
> When set_session_auth(text) is called, the effective session and current
> user is switched to the role
> On 3 Jan 2024, at 18:22, Jelte Fennema-Nio wrote:
>
>
>> 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.
>
> Depending on the desired workflow I think that could work for you too.
> Because it a
On 1/3/24 5:47 PM, Nico Williams wrote:
Though maybe `NO RESET` isn't really needed to build these, since after
all one could use an unprivileged role and a SECURITY DEFINER function
that does the `SET ROLE` following some user-defined authentication
method, and so what
On Tue, Jan 02, 2024 at 12:36:38PM -0500, Robert Haas wrote:
> 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.
But this requires upgra
On Sat, Dec 30, 2023 at 10:16:59AM -0600, Eric Hanson wrote:
> What do you think of adding a NO RESET option to the SET ROLE command?
I've wanted this forever. Consider using this to implement user
authentication mechanisms in user-defined SQL functions that use `SET
ROLE` with `NO RESET` to "log
On Tue, 2 Jan 2024 at 23:23, Michał Kłeczek wrote:
> > On 2 Jan 2024, at 18:36, Robert Haas wrote:
> > 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
On 12/31/23 1:19 PM, Joe Conway wrote:
On
12/30/23 17:19, Michał Kłeczek wrote:
On 30 Dec 2023, at 17:16, Eric Hanson
wrote:
What do you think of adding a NO RESET option to the SET ROLE
c
> On 2 Jan 2024, at 18:36, Robert Haas wrote:
>
> On Sun, Dec 31, 2023 at 2:20 PM Joe Conway wrote:
>> On 12/30/23 17:19, Michał Kłeczek wrote:
On 30 Dec 2023, at 17:16, Eric Hanson wrote:
What do you think of adding a NO RESET option to the SET ROLE command?
>>>
>>> What I
On Sun, Dec 31, 2023 at 2:20 PM Joe Conway wrote:
> On 12/30/23 17:19, Michał Kłeczek wrote:
> >> On 30 Dec 2023, at 17:16, Eric Hanson 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’
On 12/30/23 17:19, Michał Kłeczek wrote:
On 30 Dec 2023, at 17:16, Eric Hanson 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
> On 30 Dec 2023, at 17:16, Eric Hanson 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'
https://www.postgresql.org/message-id/F9428C6E-4CCC-
On 12/30/23 11:16, Eric Hanson wrote:
Hi,
What do you think of adding a NO RESET option to the SET ROLE command?
Right now Postgres can enforce data security with roles and RLS, but
role-per-end-user doesn't really scale: Db connections are per-role, so
a connection pooler can't share connec
Hi,
What do you think of adding a NO RESET option to the SET ROLE command?
Right now Postgres can enforce data security with roles and RLS, but
role-per-end-user doesn't really scale: Db connections are per-role, so a
connection pooler can't share connections across users. We can work around
th
13 matches
Mail list logo
