Re: Converting contrib SQL functions to new style

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Converting contrib SQL functions to new style
Дата
Msg-id 3566011.1618422104@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Converting contrib SQL functions to new style  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Converting contrib SQL functions to new style  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Converting contrib SQL functions to new style
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Options given both on cmd-line and in the config with different values