拡張スクリプトはサンドボックスで実行する必要がありますか？
特に、これはlua（luajit-2.0）で書かれたゲーム拡張機能に関するものです。これらのスクリプトで実行できることを制限する必要があるかどうか考えていたところ、おそらくすべきでないという結論に達しました。
正しく理解するのは難しい。ばかげて聞こえるかもしれませんが、サンドボックスがとにかく漏れてしまう可能性があります。
私が考えることができる唯一の利点は、サードパーティのスクリプトを実行するときにユーザーに安心感を与えることです。
不利な点は、拡張機能の作成者にとって非常に煩わしいことです。つまり、今のところ、私自身です（ゲームコンテンツのほとんどはスクリプト化されます）。
実際に見栄えのするものを得る前にこれを尋ねているのは、サンドボックスを早い段階で追加するのは簡単ですが、私自身にも迷惑な制限を課すためです。ただし、最初にそれを続行し、後でサンドボックスが必要だと判断した場合は、問題が発生します（既にそこにあるスクリプトを書き直すか、何らかの形の信頼管理システムを導入する必要があります）それは価値があるよりももっと厄介なようです）。
正しく理解するのは難しい
関数のホワイトリストを含むbasicサンドボックスを作成し、安全でない可能性のある関数のカスタム実装を追加することは実際にはそれほど難しくありません。この SO質問 は、良い出発点のようです。
サンドボックスがとにかく漏れてしまう可能性があります
基本的なセキュリティの提供を開始するだけで十分だと思います。いくつかの特別なディレクトリの外部にあるファイルへのアクセスを制限します。とにかく100％安全なアプリケーションというものはありません。誰かが悪意のある拡張機能を作成するとどうなるかを考えてください。ユーザーはおそらくあなたを開発者のせいにするでしょう。誰かに拡張機能を書く機会を与えることを計画している場合、最終的には何らかのセキュリティが必要になります。それがあなただけの場合-そのままでも大丈夫です。
私が考えることができる唯一の利点は、サードパーティのスクリプトを実行するときにユーザーに安心感を与えることです。
これがまさにサンドボックス化を行うべき理由whyであり、サンドボックス化に対して有効な引数ではありません。
不利な点は、それが拡張機能作成者にとって非常に煩わしいことです。
ゲームスクリプティングの経験があり、サンドボックス環境で単独で作業するのが面倒だとは思いません。私を困らせているのは、ゲーム内オブジェクトの特定のAPIやそのような貧弱な実装など、ゲームに関連する機能の欠如です。
特に良い例として [〜＃〜] love [〜＃〜] エンジンを検討すると役立つ場合があります（まだ行っていない場合）、特に filestem APIのチュートリアル =。
私は中規模から大規模のソフトウェア開発では、プログラマーは常にレイヤー交換または将来の機能のための自由設定オプションを作成しようとするビデオゲームの開発の両方を信じています。
Luaは、これらのオプションをエンドユーザーや開発者が簡単に実装できる言語ですが、ワークスペースの計画が容易であることを意味するわけではありません。エンドユーザーが動作をカスタマイズすることを許可されている場合は、今日、単純な乗算がリークする可能性もあります。
サンドボックスゲームが提供するものに焦点を合わせると、最終用途が二重ブレードになる可能性があることを理解して、ゲームを非線形で面白く楽しいものにすることができます、しかし同時に、作業領域での制限を簡単に計画することはできません。
セキュリティの観点から、それは素晴らしいですね！拡張機能の優れたテスト環境は、すべてのタイプのソフトウェア。
結論として、製品のサンドボックスを作成する価値はないと思われますが、実際には開発者または開発者のグループがより多くの利益を得るでしょう。なぜなら、エンドユーザーは開発者の環境を簡単に構成できるため、機能構造を変更します。 サンドボックスゲームは、（ソフトウェアのスケーラビリティのように）拡張機能の創造的な進化とその機能の自然な進化を可能にすることを確信しています。