Re: Converting contrib SQL functions to new style
От
Tom Lane
Тема
Re: Converting contrib SQL functions to new style
Дата
Msg-id
3567049.1618423436@sss.pgh.pa.us
Ответ на
Re: Converting contrib SQL functions to new style (Robert Haas)
Список
Дерево обсуждения
Converting contrib SQL functions to new style Tom Lane <tgl@sss.pgh.pa.us>
Re: Converting contrib SQL functions to new style Noah Misch <noah@leadboat.com>
Re: Converting contrib SQL functions to new style Tom Lane <tgl@sss.pgh.pa.us>
Re: Converting contrib SQL functions to new style Noah Misch <noah@leadboat.com>
Re: Converting contrib SQL functions to new style Robert Haas <robertmhaas@gmail.com>
Re: Converting contrib SQL functions to new style Tom Lane <tgl@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 Tom Lane <tgl@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 Tom Lane <tgl@sss.pgh.pa.us>
Re: Converting contrib SQL functions to new style Noah Misch <noah@leadboat.com>
Re: Converting contrib SQL functions to new style Andrew Dunstan <andrew@dunslane.net>
Re: Converting contrib SQL functions to new style Tom Lane <tgl@sss.pgh.pa.us>
Re: Converting contrib SQL functions to new style Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Re: Converting contrib SQL functions to new style Tom Lane <tgl@sss.pgh.pa.us>
Re: Converting contrib SQL functions to new style Mark Dilger <mark.dilger@enterprisedb.com>
Re: Converting contrib SQL functions to new style Tom Lane <tgl@sss.pgh.pa.us>
Re: Converting contrib SQL functions to new style Vik Fearing <vik@postgresfriends.org>
Re: Converting contrib SQL functions to new style Mark Dilger <mark.dilger@enterprisedb.com>
Re: Converting contrib SQL functions to new style Vik Fearing <vik@postgresfriends.org>
Re: Converting contrib SQL functions to new style Alvaro Herrera <alvherre@alvh.no-ip.org>
Robert Haas writes: > On Wed, Apr 14, 2021 at 1:41 PM Tom Lane 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 по дате отправления