public inbox for [email protected]  

help / color / mirror / Atom feed

Re: Fwd: A million users
2+ messages / 2 participants
[nested] [flat]

* Re: Fwd: A million users
@ 2024-11-22 12:57 [email protected]
  2024-11-22 23:23 ` Re: Fwd: A million users Eric Hanson <[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 12:57 Re: Fwd: A million users [email protected]
@ 2024-11-22 23:23 ` Eric Hanson <[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