From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Subject: Re: pgsql: Fix search_path to a safe value during maintenance operations.
Date: Mon, 31 Jul 2023 15:10:32 -0700
Message-ID: <fde3f0e0991d8d68c5abcf3fb54ad106e73da4e7.camel@j-davis.com> (raw)
In-Reply-To: <CA+Tgmoa5mksH1rAggYYwm0fJAO8TCnLG_oRE=su06XfqU+KTLA@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>
On Mon, 2023-07-31 at 12:53 -0400, Robert Haas wrote:
> I agree. I think there are actually two interrelated problems here.
>
> One is that virtually all code needs to run with the originally
> intended search_path rather than some search_path chosen at another
> time and maybe by a different user. If not, it's going to break, or
> compromise security, depending on the situation. The other is that
> running arbitrary code written by somebody else as yourself is
> basically instant death, from a security perspective.
Good framing.
The search_path is a particularly nasty problem in our system because
it means that users can't even trust the code that they write
themselves! A function author has no way to know how their own function
will behave under a different search_path.
> It's a little hard to imagine a world in which these problems don't
> exist at all, but it somehow feels like the design of the system
> pushes you toward doing this stuff incorrectly rather than doing it
> correctly. For instance, you can imagine a system where when you run
> CREATE OR REPLACE FUNCTION, the prevailing search_path is captured
> and
> automatically included in proconfig.
Capturing the environment is not ideal either, in my opinion. It makes
it easy to carelessly depend on a schema that others might not have
USAGE privileges on, which would then create a runtime problem for
other callers. Also, I don't think we could just depend on the raw
search_path, we'd need to do some processing for $user, and there are
probably a few other annoyances.
It's one possibility and we don't have a lot of great options, so I
don't want to rule it out though. If nothing else it could be a
transition path to something better.
> But you can maybe imagine a system where
> all code associated with a table is run as the table owner in all
> cases, regardless of SECURITY INVOKER/DEFINER, which I think would at
> least close some holes.
>
> The difficulty is that it's a bit hard to imagine making these kinds
> of definitional changes now, because they'd probably be breaking
> changes for pretty significant numbers of users.
I believe we can get close to a good model with minimal breakage. And
when we make the problem small enough I believe other solutions will
emerge. We will probably have to hedge with some compatibility GUCs.
> But on the other
> hand, if we don't start thinking about systemic changes here, it
> feels
> like we're just playing whack-a-mole.
Exactly. If we can agree on where we're going then I think we can get
there.
Regards,
Jeff Davis
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: pgsql@j-davis.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, noah@leadboat.com, nathandbossart@gmail.com
Subject: Re: pgsql: Fix search_path to a safe value during maintenance operations.
In-Reply-To: <fde3f0e0991d8d68c5abcf3fb54ad106e73da4e7.camel@j-davis.com>
* 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