Почему PL / Python не заслуживает доверия?

Это связано с объектной моделью Python - всегда есть способ получить ссылку на объекты, которые могут быть небезопасными. См. Документацию к модулю rexec и главу с ограниченным исполнением в документации для получения дополнительной информации о проблемах, а также:

Ограничения не имеют ничего общего с самим PostgreSQL, они присущи реализации интерпретатора CPython или, возможно, даже самому языку Python.

Некоторые другие языки проверяли среды выполнения, такие как Perl, Java, JavaScript и Lua. Большинство из них столкнулись с рядом проблем безопасности, поскольку такие ограниченные среды исполнения очень трудно защитить от всех возможных взломов.

На самом деле ничто не мешает PostgreSQL добавить интерпретатора Python с поличным доверием, поскольку rexec достаточно хорош для многих целей. PostgreSQL не склонен увлекаться только - в основном - достаточно хорошо - возможно, хотя. Вероятно, он будет принят только в том случае, если он помечен как суперпользовательский, но вы всегда можете предоставить доступ к нему конкретным пользователям. Это было бы лучше, чем ненадежный Python.

Лично я думаю, что PL / V8 или подобное - это будущее здесь, и я хотел бы видеть его движение в сторону поддержки в ядре.

Я также смутно исследовал идею надежного Mono, который может загружать «безопасные» сборки, написанные на C #, VB.NET, IronPython или чем-то еще, но не смог сделать много на эту тему.

Крейг Рингер
источник

Я никогда не видел это как причину, почему это считается ненадежным. По умолчанию Java, V8, TCL, R и другие считаются ненадежными. Единственная причина, по которой Perl пользуется доверием, заключается в том, что они поставляют специальную доверенную версию Perl с PostgreSQL postgresql.org/docs/11/plperl-trusted.html

TheSteve0

@ TheSteve0 Вы, возможно, не видели это как таковое, но именно поэтому это так. В PostgreSQL раньше был plpythonu, и он был удален после устаревания rexecмодуля Python как небезопасный, как указано выше. Я предполагаю, что, возможно, plpython, использующий PyPi, сможет предоставить ограниченный режим, который затем может использовать Pg. Я не смотрел, чтобы увидеть, есть ли много работы. Вы также ошибаетесь в «специальной доверенной версии Perl» - на самом деле это совершенно обычный Perl, один и тот же интерпретатор используется для plperl и plperlu. Разница заключается в конфигурации времени выполнения.

Крейг Рингер

@ TheSteve0 plperl по-разному конфигурирует экземпляры интерпретатора Perl во время выполнения. Смотрите plperl.c для подробностей о Gorey, в частности pp_require_safeи plperl_trusted_init. Я не знаю достаточно, чтобы составить мнение об истинной безопасности ограниченного исполнения Perl. Я бы предпочел увидеть доверенную версию Lua или получить лучшую поддержку и принятие, надежный интерпретатор JavaScript. Но сейчас у нас есть plperl.

Крейг Рингер

@ TheSteve0 BTW, Java JVM, использующая код Java или Groovy, или виртуальная машина Mono, использующая C # или VB.NET, кажется, имеет большой смысл, поскольку обе среды выполнения имеют надежные функции песочницы и управления безопасностью. Java SecurityManager, например. Но, к сожалению, в обеих средах исполнения используются тяжелые стартапные, многопоточные модели исполнения с общим доступом по умолчанию, которые плохо подходят для облегченного процесса PostgreSQL с общим доступом по умолчанию fork () - без модели exec. Они на самом деле не в состоянии fork (). Поэтому мы не можем использовать их очень эффективно в PostgreSQL.

Крейг Рингер

Здесь читатели могут быть заинтересованы в этой проблеме GitHub, которую я сделал в проекте Mono по поводу использования Mono в fork () runtime: github.com/mono/mono/issues/11857

Крейг Рингер,

Почему PL / Python не заслуживает доверия?

Ответы: