public inbox for [email protected]
help / color / mirror / Atom feedRe: Fwd: A million users
2+ messages / 2 participants
[nested] [flat]
* Re: Fwd: A million users
@ 2024-11-22 12:57 [email protected]
0 siblings, 1 reply; 2+ messages in thread
From: [email protected] @ 2024-11-22 12:57 UTC (permalink / raw)
To: Eric Hanson <[email protected]>; +Cc: Dominique Devienne <[email protected]>; Alvaro Herrera <[email protected]>; Vijaykumar Jain <[email protected]>; pgsql-general; [email protected] <[email protected]>
Eric Hanson:
> Did you find some way to prevent RESET ROLE? I once advocated for a NO
> RESET option on SET ROLE [1] so that RESET ROLE would be impossible for
> the rest of the session. Still think it would be helpful.
Yeah, this is still on my list of things to research more about
eventually - currently still unsolved.
For my use-case the NO RESET would need to apply until the end of the
transaction, not end of the session.
I imagine something like an extension, that would:
- block any SET SESSION ROLE
- block any RESET ROLE
- only allow SET LOCAL ROLE when CURRENT_USER has the right to do so
Then the effect of SET LOCAL ROLE would still be reversed at the end of
the transaction, but you could never "escape" a SET LOCAL ROLE that was
set earlier.
Best,
Wolfgang
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Fwd: A million users
@ 2024-11-22 23:23 Eric Hanson <[email protected]>
parent: [email protected]
0 siblings, 0 replies; 2+ messages in thread
From: Eric Hanson @ 2024-11-22 23:23 UTC (permalink / raw)
To: [email protected]; +Cc: Dominique Devienne <[email protected]>; Alvaro Herrera <[email protected]>; Vijaykumar Jain <[email protected]>; pgsql-general; [email protected] <[email protected]>
On Fri, Nov 22, 2024 at 6:57 AM <[email protected]> wrote:
> Yeah, this is still on my list of things to research more about
> eventually - currently still unsolved.
>
> For my use-case the NO RESET would need to apply until the end of the
> transaction, not end of the session.
>
> I imagine something like an extension, that would:
> - block any SET SESSION ROLE
> - block any RESET ROLE
> - only allow SET LOCAL ROLE when CURRENT_USER has the right to do so
>
> Then the effect of SET LOCAL ROLE would still be reversed at the end of
> the transaction, but you could never "escape" a SET LOCAL ROLE that was
> set earlier.
As things are now, would someone be able to do a RESET ROLE if *any*
code/function had a SQL injection vulnerability, or only if there was one
in the pooler? Or (ideally) neither. That's what a NO RESET option (or
some similar functionality) would provide with certainty.
I found this extension:
https://github.com/pgaudit/set_user
but haven't used it. Seems to address this though, they introduce a
set_session_auth(token) function and then reset_role requires the token if
session_auth has been set.
Thanks,
Eric
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-11-22 23:23 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-11-22 12:57 Re: Fwd: A million users [email protected]
2024-11-22 23:23 ` Eric Hanson <[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