Re: Question concerning backport of CVE-2022-2625
От | Roberto C. Sánchez |
---|---|
Тема | Re: Question concerning backport of CVE-2022-2625 |
Дата | |
Msg-id | Y3qjjcqjDr/C6p4H@connexer.com обсуждение исходный текст |
Ответ на | Re: Question concerning backport of CVE-2022-2625 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi Tom, On Sun, Nov 20, 2022 at 11:43:41AM -0500, Tom Lane wrote: > Roberto =?iso-8859-1?Q?C=2E_S=E1nchez?= <roberto@debian.org> writes: > > -- this makes a shell "point <<@@ polygon" operator too > > CREATE OPERATOR @@>> ( PROCEDURE = poly_contain_pt, > > LEFTARG = polygon, RIGHTARG = point, > > COMMUTATOR = <<@@ ); > > CREATE EXTENSION test_ext_cor; -- fail > > ERROR: operator <<@@(point,polygon) is not a member of extension "test_ext_cor" > > DETAIL: An extension is not allowed to replace an object that it does not own. > > DROP OPERATOR <<@@ (point, polygon); > > CREATE EXTENSION test_ext_cor; -- now it should work > > +ERROR: operator 16427 is not a member of extension "test_ext_cor" > > +DETAIL: An extension is not allowed to replace an object that it does not own. > > That is ... odd. Since 9.4 is long out of support I'm unenthused > about investigating it myself. (Why is it that people will move heaven > and earth to fix "security" bugs in dead branches, but ignore even > catastrophic data-loss bugs?) But if you're stuck with pursuing > this exercise, I think you'd better figure out exactly what's > happening. I agree that it smells like c94959d41 could be related, > but I don't see just how that'd produce this symptom. Before that > commit, the DROP OPERATOR <<@@ would have left a dangling link > behind in @@>> 's oprcom field, but there doesn't seem to be a > reason why that'd affect the test_ext_cor extension: it will not > be re-using the same operator OID, nor would it have any reason to > touch @@>>, since there's no COMMUTATOR clause in the extension. > I understand your reticence to dive into a branch that is long dead from your perspective. That said, I am grateful for the insights you provided here. > It'd likely be a good idea to reproduce this with a gdb breakpoint > set at errfinish, and see exactly what's leading up to the error. > Thanks for this suggestion. I will see if I am able to isolate the precise cause of the failure with this. Regards, -Roberto -- Roberto C. Sánchez
В списке pgsql-hackers по дате отправления: