Re: Extension pg_trgm, permissions and pg_dump order
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>, Färber, Franz-Josef (StMUK) <Franz-Josef.Faerber@stmuk.bayern.de>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-05-27T19:29:07Z
Lists: pgsql-bugs, pgsql-general
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
Commits
-
CREATE INDEX: use the original userid for more ACL checks.
- 88b39e61486a 10.22 landed
- 6d49cc28613b 11.17 landed
- 93731d549e15 12.12 landed
- 8782ce49e4d0 13.8 landed
- ace9973867c2 14.5 landed
- 00377b9a02b8 15.0 landed