Re: Marking some contrib modules as trusted extensions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Marking some contrib modules as trusted extensions
Дата
Msg-id 13921.1581638230@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Marking some contrib modules as trusted extensions  (Andres Freund <andres@anarazel.de>)
Ответы Re: Marking some contrib modules as trusted extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Marking some contrib modules as trusted extensions  (Andres Freund <andres@anarazel.de>)
Re: Marking some contrib modules as trusted extensions  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2020-01-29 14:41:16 -0500, Tom Lane wrote:
>> pgcrypto

> FWIW, given the code quality, I'm doubtful about putting itq into the trusted
> section.

I don't particularly have an opinion about that --- is it really that
awful?  If there is anything broken in it, wouldn't we consider that
a security problem anyhow?

> Especially with FROM UNPACKAGED it seems like it'd be fairly easy to get
> an extension script to do dangerous things (as superuser). One could
> just create pre-existing objects that have *not* been created by a
> previous version, and some upgrade scripts would do pretty weird
> stuff. There's several that do things like updating catalogs directly
> etc.  It seems to me that FROM UNPACKAGED shouldn't support trusted.

Hmm, seems like a reasonable idea, but I'm not quite sure how to mechanize
it given that "unpackaged" isn't magic in any way so far as extension.c
is concerned.  Maybe we could decide that the time for supporting easy
updates from pre-9.1 is past, and just remove all the unpackaged-to-XXX
scripts?  Maybe even remove the "FROM version" option altogether.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: error context for vacuum to include block number
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Marking some contrib modules as trusted extensions