From: | Joseph Koshakow <koshy44(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(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-07-08 23:08:35 |
Message-ID: | CAAvxfHeUKFE-=biJO15mMD5SNFSqDJy1zX2G-4=tDQkwfaBosg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jul 8, 2023 at 6:09 PM Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:
>> I think the issue here is that if a session loses the ability to set
>> their session authorization in the middle of a transaction, then
>> rolling back the transaction may fail and cause the server to panic.
>> That's probably what the deleted comment mean when it said:
>>
>>> * It's OK because the check does not require catalog access and can't
>>> * fail during an end-of-transaction GUC reversion
>
> Yeah. IIUC the ERROR longjmps to a block that calls AbortTransaction(),
> which ERRORs again when resetting the session authorization, which causes
> us to call AbortTransaction() again, etc., etc.
Everything seems to work fine if the privilege check is moved to
check_session_authorization. Which is maybe what the comment meant
instead of assign_session_authorization.
I've attached a patch with this change.
Thanks,
Joe Koshakow
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Prevent-non-superusers-from-altering-session-auth.patch | text/x-patch | 6.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2023-07-09 00:03:42 | Re: check_strxfrm_bug() |
Previous Message | Nathan Bossart | 2023-07-08 22:09:04 | Re: Preventing non-superusers from altering session authorization |