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 3566011.1618422104@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  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 14, 2021 at 10:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The situation of interest is where you are trying to install an extension
>> into a schema that also contains malicious objects.  We've managed to make
>> most of the commands you might use in an extension script secure against
>> that situation, and Noah wants to hold SQL-function creation to that same
>> standard.

> Oh, I was forgetting that the creation schema has to be first in your
> search path. :-(

> Does the idea of allowing the creation schema to be set separately
> have any legs? Because it seems like that would help here.

Doesn't help that much, because you still have to reference objects
already created by your own extension, so it's hard to see how the
target schema won't need to be in the path.

[ thinks for awhile ... ]

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Converting contrib SQL functions to new style
Next
From: Tom Lane
Date:
Subject: Re: Options given both on cmd-line and in the config with different values