Re: Fix search_path for all maintenance commands

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(at)singh(dot)im> wrote:
> > On Thu, Jul 13, 2023 at 1:37 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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.