pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: michael@paquier.xyz
Cc: gurjeet@singh.im
Cc: pgsql-hackers@postgresql.org
Subject: Re: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS
Date: Sun, 24 Jul 2022 20:40:40 -0700
Message-ID: <20220725034040.GA4085281@nathanxps13> (raw)
In-Reply-To: <954936.1658597004@sss.pgh.pa.us>
References: <CABwTF4U9v4u3L2GWU6ZVxK-6NtvEMarrgAj2Vq8=wE_g1Tkncw@mail.gmail.com>
	<CABwTF4WXCbjEpVRq+G+MZeJEXU=2evYMb_DVdzXpWap5cczkcQ@mail.gmail.com>
	<Ytn2ssEKdzPFM3Vf@paquier.xyz>
	<20220722.151600.1094104349120879204.horikyota.ntt@gmail.com>
	<729330.1658516182@sss.pgh.pa.us>
	<20220722223359.GB3998906@nathanxps13>
	<763512.1658529844@sss.pgh.pa.us>
	<20220722225615.GC3998906@nathanxps13>
	<954936.1658597004@sss.pgh.pa.us>

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





view thread (25+ messages)  latest in thread

Message-ID: <20220725034040.GA4085281@nathanxps13>
Permalink:  ../20220725034040.GA4085281@nathanxps13/
Also on:    postgresql.org/message-id/20220725034040.GA4085281@nathanxps13

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: nathandbossart@gmail.com, tgl@sss.pgh.pa.us, horikyota.ntt@gmail.com, michael@paquier.xyz, gurjeet@singh.im
  Subject: Re: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS
  In-Reply-To: <20220725034040.GA4085281@nathanxps13>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox