LINUX.ORG.RU

Скрипты клиента или сложный вопрос безопасности и выбора языка для скриптов.


0

0

Необходимо найти решение для исполнение скриптов на стороне клиента. Созданных кем угодно на стороне. Мультиплатформенно.

Нужно изначально предупредить любые зловредные действия.

Мораль - клиентсайд скрипты должны работать в "песочнице", не имея никакого доступа к системе кроме строго отведённого.

У Java, в принципе, с этим должно быть хорошо. Её апплеты на такое применение рассчитаны изначально. Соответственно, если в качестве скриптов будут задействованы апплеты - с безопасностью всё хорошо. Правда остаётся вопрос привязки апплетов к своему клиенту.

У Форта тоже всё хорошо. Свой урезанный словарь без доступа к базовому словарю - и опаньки.

Что с этим у Питона?

Какие есть ещё альтернативы?

JavaScript неинтересен из-за его производительности.

★★★★★

Ну на главной странице про Lua пишут :) Вроде с производительностью там всё нормально, контролировать AFAIK можно всё что нужно.

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

Мне тоже сразу Lua в голову пришла. :) Чего-чего, а песочницу там устроить элементарно.

Teak ★★★★★
()

perldoc Safe, в принципе.

Хотя я бы, действительно, смотрел на lua скорее - хотя граблей в нем поналожено, говорят, немало. Ну и JS бы не отбрасывал - язык-то хороший, а производительность для client-side скриптинга редко так уж важна.

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

> хотя граблей в нем поналожено, говорят, немало

Кто говорит? И вообще какого рода грабли? В плане безопасности песочницы их нет и быть не может. Выдаёшь программке только те функции, что ей нужны, и всё. Lua маленькая, в ней легко разобраться, perl же настолько огромен и запутан, что вряд ли можно быть уверенным, что ты действительно отрубил скрипту _все_ возможности нагадить.

Наверное forth тоже неплох в этом смысле, но сдаётся мне, что среднестатистическому "кому угодно на стороне" lua покажется гораздо более простой для освоения. :)

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

>!#/usr/bin/perl -wT

И как потом из Перла юзать объекты вызвавшего окружения? :)

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

>Наверное forth тоже неплох в этом смысле, но сдаётся мне, что среднестатистическому "кому угодно на стороне" lua покажется гораздо более простой для освоения. :)

Да, на эти грабли уже наступалось :)

KRoN73 ★★★★★
() автор топика

В тикле замечательно - safeTcl рулит. Плюс синтаксис элементарный, дальше ехать некуда. В Common Lisp можно подобное забабахать, но уже более сложным путём - собственный пэкедж, плюс запрет на использование префикса. В Scheme сравнительно легко.

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

>bash in chroot?

Под виндой? И как потом из этого чрута управлять 3D-объектами вызывающего клиента?

...

Вообще, чем дальше, тем больше мысли к JVM склоняются. Широкий выбор разнокалиберных языков, отработанная система безопасности на Java-апплетах, приличная производительность...

Но тогда возникает большая проблема с имеющимися планами писать клиент первого этапа на Питоне. А войну с нашими Питонерами я не выдержу :D

KRoN73 ★★★★★
() автор топика

У руби тоже есть механизм защиты. Не жабский, конечно, но есть.

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

>Такое ощущение, что ты еще до поста решил с jvm работать :) Зачем тогда спрашивать?

Мне очень хочется, но нужно себя ещё убедить. И не только себя :) А так - изначально первый этап планируется на Питоне... Но дальше я уже писал выше :)

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

Ну пусть доработают до 2.4:) А для не очень сложного скриптования и 2.2 вполне достаточно.

krum
()

>Какие есть ещё альтернативы?

А ещё есть HaskellScript...

''' Правда он похоже сдохнет. Но идея хороша. '''

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

Кстати да, afaik unrealscript и есть lua. Можно взять cquake из quake:)

krum
()
Ответ на: комментарий от Teak

>Или ты её просто не знаешь? Потрать несколько часов.

Изучить синтаксис языка и изучить особенности его привязки - это два порядка разницы :) Впрочем, посмотрю, конечно... Правда, ещё есть LuaJava :D

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

> python restricted execution - может, подойдет.

Вряд ли. С этим всё очень плохо. Python'овцы на это в результате положили с прибором.

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

> ещё есть LuaJava

Не смотрел, конечно, но это какое-то извращение.

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

> > хотя граблей в нем поналожено, говорят, немало

> Кто говорит? И вообще какого рода грабли? В плане безопасности песочницы их нет и быть не может. Выдаёшь программке только те функции, что ей нужны, и всё.

Грабли в языке. Люди, писавшие на нем довольно сложные системы (AI-скриптинг коммерческой игры) говорят, что есть неочевидые проблемы с семантикой-синтаксисом самого языка. Типа ты думаешь, что написал одно, а на самом деле оно молча делает другое.

> Lua маленькая, в ней легко разобраться, perl же настолько огромен и запутан, что вряд ли можно быть уверенным, что ты действительно отрубил скрипту _все_ возможности нагадить.

в perldoc Opcode все неплохо расписано. Всего-то ~350 опкодов.

> Наверное forth тоже неплох в этом смысле, но сдаётся мне, что среднестатистическому "кому угодно на стороне" lua покажется гораздо более простой для освоения. :)

Вероятно.

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

> неочевидые проблемы с семантикой-синтаксисом самого языка. Типа ты думаешь, что написал одно, а на самом деле оно молча делает другое.

Как-то это неконкретно. Я почему интересуюсь: я его маленько юзал (хотя до реального применения дело не дошло), и я просто не очень понимаю, что там может быть неочевидного? По нему есть ровно две книжки, которые надо прочитать, это занимает день, ну от силы два. После этого никаких вопросов по-моему быть не может в принципе. Вот мне и интересен пример хотя бы одной такой грабли. Может я где-то не там ходил. :)

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

Ruby с его safe level будет хорошим выбором.

anonymous
()

посмотри язык E http://www.erights.org/ -- делали как раз для твоих целей. красивый ООП без классов, безопасность через контракты, и (любимая?) jvm в одной куче. а что еще нужно для щастья?... :)

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

> Как-то это неконкретно. Я почему интересуюсь: я его маленько юзал (хотя до реального применения дело не дошло), и я просто не очень понимаю, что там может быть неочевидного? По нему есть ровно две книжки, которые надо прочитать, это занимает день, ну от силы два. После этого никаких вопросов по-моему быть не может в принципе. Вот мне и интересен пример хотя бы одной такой грабли. Может я где-то не там ходил. :)

Ну мопед не мой, я сам на Луа не писал. Я вообще против него ничего не имею - просто предупреждаю, что your mileage may vary.

В качестве примера приводили что-то в духе того, что в старых версиях ruby код return a + b парсился как return(a) + b. Делал он, соотвественно, нихрена не то, что подразумевается. Конкретно это, кажется, исправили - но вроде, на что-то еще такого плана жаловались.

anonymous
()
Ответ на: комментарий от krum

не, это был баг в языке - вот такие странные там правила приоритетов. Пофиксили это тем, что return теперь обязательно требует скобки.

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