Re: Fix search_path for all maintenance commands

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Gurjeet Singh <gurjeet@singh.im>, Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@postgresql.org, Nathan Bossart <nathandbossart@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Greg Stark <stark@mit.edu>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2023-07-15T21:13:33Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix search_path to a safe value during maintenance operations.

  2. Make relation-enumerating operations be security-restricted operations.

On Thu, Jul 13, 2023 at 02:07:27PM -0700, David G. Johnston wrote:
> On Thu, Jul 13, 2023 at 2:00 PM Gurjeet Singh <gurjeet@singh.im> wrote:
> > On Thu, Jul 13, 2023 at 1:37 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
> > >  I'm against simply breaking the past without any recourse as what we
> > did for pg_dump/pg_restore still bothers me.
> >
> > I'm sure this is tangential, but can you please provide some
> > context/links to the change you're referring to here.
>
> Here is the instigating issue and a discussion thread on the aftermath:
> https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058%3A_Protect_Your_Search_Path
> https://www.postgresql.org/message-id/flat/13033.1531517020%40sss.pgh.pa.us#2aa2e25816d899d62f168926e3ff17b1

I don't blame you for feeling bothered about it.  A benefit of having done it
is that we gained insight into the level of pain it caused.  If it had been
sufficiently painful, someone would have quickly added an escape hatch.  Five
years later, nobody has added one.

The 2018 security fixes instigated many function repairs that $SUBJECT would
otherwise instigate.  That wasn't too painful.  The net new pain of $SUBJECT
will be less, since the 2018 security fixes prepared the path.  Hence, I
remain +1 for the latest Davis proposal.