Re: Converting contrib SQL functions to new style - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Converting contrib SQL functions to new style
Date
Msg-id 3567049.1618423436@sss.pgh.pa.us
Whole thread Raw
In response to Re: Converting contrib SQL functions to new style  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Converting contrib SQL functions to new style  (Andrew Dunstan <andrew@dunslane.net>)
Re: Converting contrib SQL functions to new style  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 14, 2021 at 1:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Could we hack things so that extension scripts are only allowed to
>> reference objects created (a) by the system, (b) earlier in the
>> same script, or (c) owned by one of the declared prerequisite
>> extensions?  Seems like that might provide a pretty bulletproof
>> defense against trojan-horse objects, though I'm not sure how much
>> of a pain it'd be to implement.

> That doesn't seem like a crazy idea, but the previous idea of having
> some magic syntax that means "the schema where extension FOO is" seems
> like it might be easier to implement and more generally useful.

I think that's definitely useful, but it's not a fix for the
reference-capture problem unless you care to assume that the other
extension's schema is free of trojan-horse objects.  So I'm thinking
that we really ought to pursue both ideas.

This may mean that squeezing these contrib changes into v14 is a lost
cause.  We certainly shouldn't try to do what I suggest above for
v14; but without it, these changes are just moving the security
issue to a different place rather than eradicating it completely.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Converting contrib SQL functions to new style
Next
From: Tom Lane
Date:
Subject: Re: Possible typo/unclear comment in joinpath.c