From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Gurjeet Singh <gurjeet(at)singh(dot)im>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fwd: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS |
Date: | 2022-07-21 23:30:20 |
Message-ID: | 348146.1658446220@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> + StartTransactionCommand();
> process_session_preload_libraries();
> + CommitTransactionCommand();
Yeah, that way would avoid any questions about changing the order of
operations, but it seems like a mighty expensive solution: it's
adding a transaction to each backend start on the off chance that
(a) session_preload_libraries/local_preload_libraries is nonempty and
(b) the loaded libraries are going to do anything where it'd matter.
So that's why I thought of moving the call inside a pre-existing
transaction.
If we had to back-patch this into any released versions, I'd agree with
taking the performance hit in order to reduce the chance of side-effects.
But I think as long as we only have to do it in v15, it's not too late to
possibly cause some compatibility issues for extensions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2022-07-21 23:35:16 | Re: Fwd: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS |
Previous Message | Jacob Champion | 2022-07-21 23:29:35 | Re: [PATCH] Log details for client certificate failures |