Re: Extension pg_trgm, permissions and pg_dump order
От | Robert Haas |
---|---|
Тема | Re: Extension pg_trgm, permissions and pg_dump order |
Дата | |
Msg-id | CA+TgmoZ9BfWUTvfrcRa4jCGS9ca7XWhYNHPzwfojAu6n6st+Dg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Extension pg_trgm, permissions and pg_dump order (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Extension pg_trgm, permissions and pg_dump order
|
Список | 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 по дате отправления: