Re: Extension pg_trgm, permissions and pg_dump order - Mailing list pgsql-bugs

From Robert Haas
Subject Re: Extension pg_trgm, permissions and pg_dump order
Date
Msg-id CA+TgmoZ9BfWUTvfrcRa4jCGS9ca7XWhYNHPzwfojAu6n6st+Dg@mail.gmail.com
Whole thread Raw
In response to Re: Extension pg_trgm, permissions and pg_dump order  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extension pg_trgm, permissions and pg_dump order
List pgsql-bugs
On Fri, May 27, 2022 at 2:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Why isn't the current behavior - i.e. failing with a permissions error
> > - correct? I mean I realize it's wrong in the sense that you can't
> > restore a dump you just took, but what about from a security
> > perspective?
>
> From the security perspective it may be just fine.  Nonetheless,
> we need to un-break pg_dump; it's not optional for that to work.

That's pretty obvious. What's not obvious - at least to me - is
whether the kinds of changes that Noah is proposing to make here have
the effect of putting back the security vulnerability that the
original commit was intended to fix. If we decide that reverting and
living with the vulnerability is the only option, so be it. But we
shouldn't *accidentally* destroy the security that the commit that
caused the problem was trying to create.

To put that another way, there should be some kind of understandable
theory behind whatever the code does. I get nervous when we start
talking about making this bit of the code work this way and this other
bit work that way. If we don't know why we're doing that, other than
"to make it work," then I think we can't have much confidence in the
result ... even if it does, in fact, "make it work."

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Extension pg_trgm, permissions and pg_dump order
Next
From: Tom Lane
Date:
Subject: Re: Extension pg_trgm, permissions and pg_dump order