Re: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS
От | Nathan Bossart |
---|---|
Тема | Re: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS |
Дата | |
Msg-id | 20220725034040.GA4085281@nathanxps13 обсуждение исходный текст |
Ответ на | Re: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS
|
Список | pgsql-hackers |
On Sat, Jul 23, 2022 at 01:23:24PM -0400, Tom Lane wrote: > - /* > - * process any libraries that should be preloaded at backend start (this > - * likewise can't be done until GUC settings are complete) > - */ > - process_session_preload_libraries(); This patch essentially moveѕ the call to process_session_preload_libraries() to earlier in PostgresMain(). The discussion upthread seems to indicate that this is okay. I did notice that the log_disconnections handler won't be set up yet, so failures due to session_preload_libraries won't be logged the same way as before. Also, the call to pgstat_report_connect() won't happen. Neither of these strikes me as particularly bad, but it seemed worth noting. > + * load_session_libraries: TRUE to honor session_preload_libraries nitpick: Should we call out local_preload_libraries here, too? > + if (load_session_libraries) > + process_session_preload_libraries(); I noticed that a couple of places check whether whereToSendOutput is set to DestRemote to determine if this is an interactive session. Maybe something like if (whereToSendOutput == DestRemote && !am_walsender) would be a reasonably future-proof way to avoid the need for a new InitPostgres() argument. Otherwise, the patch looks good to me. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: