Должны ли скрипты расширения выполняться в песочнице?

В частности, речь идет о расширениях игры, написанных на lua (luajit-2.0). Я размышлял, должен ли я ограничить то, что могут делать эти сценарии, и пришел к выводу, что, вероятно, я не должен:

• Трудно получить права. Звучит глупо, но, скорее всего, моя песочница все равно протечет.

• Единственное преимущество, о котором я могу подумать, - это дать пользователям чувство безопасности при запуске сторонних скриптов.

• Недостатки в том, что это просто невероятно раздражает авторов расширений. То есть на данный момент я сам (игровой контент будет в основном скриптовым).

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

Я считаю, что как при разработке видеоигры, которая при любой разработке программного обеспечения средних и больших размеров, программист всегда будет пытаться создать обмен слоями или свободно заданные варианты будущей функциональности.

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

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

С точки зрения безопасности это звучит фантастически! хорошая тестовая среда для расширений, должна быть реализована во всех типах программного обеспечения.

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

Трудно получить право

На самом деле не так сложно создать базовую песочницу с белым списком функций, а затем добавить пользовательские реализации потенциально небезопасных функций. Этот ТАК вопрос кажется хорошей отправной точкой.

но, скорее всего, моя песочница всё равно будет дырявой

Я думаю, что было бы достаточно для начала обеспечить некоторую базовую безопасность: ограничение доступа к файлам за пределами некоторых специальных каталогов. В любом случае нет такой вещи, как 100% безопасные приложения. Подумайте, что может произойти, если кто-то напишет какое-нибудь вредоносное расширение: пользователи, вероятно, будут обвинять вас как разработчика. Если вы планируете дать кому-то возможность написать расширение, вам в конечном итоге понадобится некоторая безопасность. Если это только ты - это нормально, как есть.

Единственное преимущество, о котором я могу подумать, - это дать пользователям чувство безопасности при запуске сторонних скриптов.

Именно поэтому вы должны заниматься песочницей, а это недопустимый аргумент против песочницы.

Недостатками было бы то, что это просто невероятно раздражает для авторов расширений

У меня есть некоторый опыт в игровых сценариях, и я не нахожу раздражающим работать в изолированной среде сам по себе. Что меня раздражает, так это отсутствие функциональности, которая связана с игрой, например, специфические API-интерфейсы внутриигровых объектов или плохая их реализация.

Это может помочь, если вы посмотрите на движок LOVE в качестве хорошего примера (если вы этого еще не сделали), особенно на учебник по API файловой системы .