From: | Roberto C(dot) Sánchez <roberto(at)debian(dot)org> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Question concerning backport of CVE-2022-2625 |
Date: | 2022-11-20 22:00:45 |
Message-ID: | Y3qjjcqjDr/C6p4H@connexer.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)debian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-11-20 22:26:11 | Re: perform_spin_delay() vs wait events |
Previous Message | Thomas Munro | 2022-11-20 21:53:52 | Re: More efficient build farm animal wakeup? |