Message-ID: <fd425bbacb86a00b85aabcbaa78d55c55cbf6fc3.camel@j-davis.com>
Subject: Re: pgsql: Fix search_path to a safe value during maintenance
 operations.
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>, Joe Conway <mail@joeconway.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>,
	"pgsql-hackers@postgresql.org"
	 <pgsql-hackers@postgresql.org>, Nathan Bossart <nathandbossart@gmail.com>
Date: Mon, 31 Jul 2023 14:15:49 -0700
In-Reply-To: 
 <CA+TgmoYgdzEX6kti4ycZC2DmtX4VPAWcu45U5K+RAzCPp9sUpw@mail.gmail.com>
References: <E1q7j7Y-000z1H-Hr@gemulon.postgresql.org>
	 <89a415b86d5421941e4281ba5bf6288934078624.camel@j-davis.com>
	 <d20864b929ff769a0ebf772359719f05bb6982cd.camel@j-davis.com>
	 <573014.1686375211@sss.pgh.pa.us>
	 <20230612170510.GA201972@gust.leadboat.com>
	 <f53df2dbe11bb42764bcdd003a54aa29c9bb6137.camel@j-davis.com>
	 <20230613182920.GA259321@gust.leadboat.com>
	 <1799839.1686687804@sss.pgh.pa.us>
	 <4df537f5a0d8c0ceac3eec3809d1144880b8e76d.camel@j-davis.com>
	 <CA+TgmoYtJU0KknWr11W--wK=4eJtdHOgupyT=beZVPC8P=o+YA@mail.gmail.com>
	 <578fb4be80247570e6a05924908765a0b345971e.camel@j-davis.com>
	 <CA+TgmoZVCHERUkXhAMT2Er-sKBc5C6_iX+TpxxivBevDHzq2TQ@mail.gmail.com>
	 <43bbc9f7318057f51552d5986830908cb018dadf.camel@j-davis.com>
	 <1659699.1688086436@sss.pgh.pa.us>
	 <fff566293c9165c69bb4c555da1ac02c63660664.camel@j-davis.com>
	 <CA+Tgmoa5mksH1rAggYYwm0fJAO8TCnLG_oRE=su06XfqU+KTLA@mail.gmail.com>
	 <a35ef296-9438-2194-9c6c-807b2f174b0c@joeconway.com>
	 <CA+TgmoYgdzEX6kti4ycZC2DmtX4VPAWcu45U5K+RAzCPp9sUpw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/fd425bbacb86a00b85aabcbaa78d55c55cbf6fc3.camel%40j-davis.com>
Precedence: bulk

On Mon, 2023-07-31 at 16:06 -0400, Robert Haas wrote:
> if you
> include in your search_path a schema to which some other user can
> write, you are pretty much agreeing to execute code provided by that
> user.

Agreed on all counts here. I don't think it's reasonable for us to try
to make such a setup secure, and I don't think users have much need for
such a setup anyway.

> One thing we might be able to do to prevent that sort of thing is to
> have a feature to prevent "accidental" code execution, as in the
> "function trust" mechanism proposed previously. Say I trust all users
> who can SET ROLE to me and/or who inherit my privileges. Additionally
> I can decide to trust users who do neither of those things by some
> sort of explicit declaration. If I don't trust a user then if I do
> anything that would cause code supplied by that user to get executed,
> it just errors out:
>=20
> ERROR: role "rhaas" should not execute arbitrary code provided by
> role "jconway"
> HINT: If this should be allowed, use the TRUST command to permit it.

+1, though I'm not sure we need an extensive trust mechanism beyond
what we already have with the SET ROLE privilege.

> And
> we probably also still need to find ways to control search_path in a
> lot more widely than we do today. Otherwise, even if stuff is
> technically secure, it may just not work.

+1.

Regards,
	Jeff Davis