| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Joseph Koshakow <koshy44(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Preventing non-superusers from altering session authorization |
| Date: | 2023-06-23 17:54:16 |
| Message-ID: | 20230623175416.GA1268820@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 22, 2023 at 06:39:45PM -0400, Joseph Koshakow wrote:
> On Wed, Jun 21, 2023 at 11:48 PM Nathan Bossart <nathandbossart(at)gmail(dot)com>
> wrote:
>> I see that RESET SESSION AUTHORIZATION
>> with a concurrently dropped role will FATAL with your patch but succeed
>> without it, which could be part of the reason.
>
> That might be a good change? If the original authenticated role ID no
> longer exists then we may want to return an error when trying to set
> your session authorization to that role.
I was curious why we don't block DROP ROLE if there are active sessions for
the role or terminate any such sessions as part of the command, and I found
this discussion from 2016:
https://postgr.es/m/flat/56E87CD8.60007%40ohmu.fi
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2023-06-23 19:23:43 | Problems with estimating OR conditions, IS NULL on LEFT JOINs |
| Previous Message | Andres Freund | 2023-06-23 16:37:47 | Re: Assert while autovacuum was executing |