扩展脚本是否应该在沙箱中运行？

特别是，这是关于用lua（luajit-2.0）编写的游戏扩展的。我正在考虑是否应该限制这些脚本可以做什么，并得出一个结论，我可能不应该这样做：

• 很难正确。听起来很傻，但是我的沙箱很有可能最终还是漏水。

• 我唯一想到的好处就是在运行第三方脚本时为用户提供某种安全感。

• 不利之处在于，它对于扩展编写者来说是非常令人讨厌的。也就是说，就目前而言，我本人（游戏内容将主要编写脚本）。

我现在问这个问题的原因是，在我真正拥有任何可展示的东西之前，尽早添加沙箱很容易，但是也会对我自己施加恼人的限制。但是，如果我先继续使用它，然后再决定我确实需要沙箱，那我会遇到问题（我要么不得不重写已经存在的脚本，要么引入某种形式的信任管理系统这似乎比它的价值还要麻烦）。

我相信无论是视频游戏的开发，还是任何中型尺寸的软件开发，程序员都将始终尝试为将来的功能创建层交换或自由设置选项。

Lua是一种语言，它使最终用户和开发人员都可以轻松实现这些选项，但这并不意味着就可以轻松规划您的工作空间，根据我今天的经验，简单乘法也可能会泄漏，是否允许最终用户自定义其行为。

如果我们专注于沙盒游戏所提供的功能，那么我们可能会明白，最终用途可以是双刃剑，从而使游戏变得非线性，有趣和有趣，但同时也不是容易的计划他们在工作区域的极限。

从安全角度来看，这听起来很棒！一个好的扩展测试环境，应该在所有类型的软件中实现。

总而言之，我可以说，尽管似乎不值得为您的产品制作沙盒，但实际上，开发人员或开发人员组将获得更多好处，因为最终用户可以轻松地在开发人员处配置您的环境，因此花费的时间也更少了。更改功能结构。我坚信沙盒游戏（如软件可伸缩性）可以使扩展的创意不断发展，其功能也自然而然地发展。

很难正确

创建具有功能白名单的基本沙箱，然后添加潜在不安全功能的自定义实现，实际上并不是很困难。这样的问题似乎是一个很好的起点。

但是我的沙盒很有可能最终还是会漏水

我认为开始提供一些基本的安全性就足够了：限制对某些特殊目录外部文件的访问。无论如何，没有100％安全的应用程序之类的东西。想想如果有人编写恶意扩展会发生什么情况：用户可能会责怪您作为开发人员。如果您打算给某人写扩展的机会，那么最终将需要一定的安全性。如果只有你，那就可以了。

我唯一想到的好处就是在运行第三方脚本时为用户提供某种安全感。

这正是原因为什么你应该做的沙盒，它不是针对沙盒的有效论据。

缺点是对于扩展编写者来说这非常令人讨厌

我在游戏脚本编写方面有一些经验，但我自己觉得在沙盒环境中工作并不令人讨厌。令我烦恼的是缺乏与游戏相关的功能，例如游戏中对象的特定API或此类应用的不良实现。

如果您将LOVE引擎作为一个很好的示例（如果您还没有），可能会有所帮助，尤其是关于filesytem API的教程。