LINUX.ORG.RU

безопасное встраивание ficl


0

1

Hi all,

Хочу попробовать внедрить реализацию FORTH-а - ficl в одно приложение. Нравится в нем буквально все: простота embedding-а, гибкий синтаксис, который очень здорово можно пристроить в роли командного языка, однако есть одно но: ficl беспощадно падает при некорректной работе с адресами.

Т.е. например

0 1234 !

приведет к обвалу ficl-а и, соответственно, процесса, в котором этот ficl-интерпретатор вызывался.

Все логично, форт есть форт. Но выносить такие возможности на уровень пользовательских скриптов не хочется. Может кто подскажет, как наиболее адекватно можно (можно-ли) защитить программу от такого...

Что первое приходит на ум:

1. вынести форт в отдельный процесс, обмениваться с основным процессом сообщениями; позволить ему погибнуть при SIGSEGV, рестартовать по получении сигнала о гибели потомка, вроде как по модели Erlang; насколько я могу понять, подобным образом действует FTH - наследник FICL-а;

2. ограничить набор слов доступных пользователю определенным словарем, ограничивающим свободу самореализации;

1-ое выглядит не то чтобы очень трудоемко, но как-то громоздко, код изолирования ficl-а в отдельный процесс наверняка получится значительно больше собственно кода интеграции. 2-е решение кажется очень уж негибким и так-же не лишенным громоздкости, ибо предется оборачивать почти все стандартные слова.

Подскажите, кто сталкивался... наверняка есть способ проще.

Подскажите, кто сталкивался... наверняка есть способ проще.

Написать свой Форт? Тем более, что тебе все равно придётся добавлять в него доступ к функциям из основной программы.

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

> Написать свой Форт? Тем более, что тебе все равно придётся добавлять в него доступ к функциям из основной программы.

звучит сомнительно... думаешь переписать форт будет менее трудоемкой задачей, чем то что предложено? К тому же в ficl доступ к функциям программы добавляется несколькими строчками...

tentaclius
() автор топика

вариант 3

Предвидя рано или поздно такой ответ, добавлю сам :)

3. использовать fth/tcl/io/guile/??? и не выпендриваться.

Неплохой вариант, и мне он тоже в общем по душе. Просто манит именно гибкость и простота форта и хочется разобраться возможен ли subj.

К тому же программа в общем пишется для души, и если доведется допилить ее до состояния, в котором ей можно будет поделиться, что-нибудь из вышеперечисленных языков тоже будет включено (сейчас любуюсь io, хоть он и не так элегантен как язык консоли)

tentaclius
() автор топика

> как наиболее адекватно можно (можно-ли) защитить программу от такого...

Делать _интерпретатор_. С рантайм-проверками всего и вся, угу.

LamerOk ★★★★★
()
Ответ на: комментарий от Begemoth

да... походу не спасет. вернее убережет но не от всего.

таким способом все-таки можно предотвратить некоторого рода выстрелы себе в ногу, ведь если процесс таки получил сигнал, значит запись по адресу не состоялась, нет? Но это не помешает скрипту похерить живые участки памяти по неверному адресу без сигналов.

Похоже единственный путь - городить огород поверх интерпретатора или выбирать средства, лучше подходящие к цели...

tentaclius
() автор топика

> Хочу попробовать внедрить реализацию FORTH-а - ficl в одно приложение. Нравится в нем буквально все: простота embedding-а, гибкий синтаксис, который очень здорово можно пристроить в роли командного языка

Может лучше 4th использовать?

Led ★★★☆☆
()
Ответ на: вариант 3 от tentaclius

> 3. использовать fth/tcl/io/guile/??? и не выпендриваться.

Можно ещё Lua туда же добавить.

AnDoR ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.