| From: | walther(at)technowledgy(dot)de |
|---|---|
| To: | Eric Hanson <eric(at)aquameta(dot)com> |
| Cc: | Dominique Devienne <ddevienne(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>, "kaare(at)jasonic(dot)dk" <kaare(at)jasonic(dot)dk> |
| Subject: | Re: Fwd: A million users |
| Date: | 2024-11-22 12:57:45 |
| Message-ID: | c607b5e4-93c9-4c3d-9a1c-e3210ab91fb8@technowledgy.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2024-11-22 13:43:58 | Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10 |
| Previous Message | Eric Hanson | 2024-11-22 12:24:10 | Re: Fwd: A million users |