在服务器上安全执行用户提交的Python代码
我正在考虑启动一个项目，该项目涉及执行用户通过 HTML 表单输入的 python 代码。我知道这可能是致命的（exec），但我至少在
我向 Python Challenge 的开发人员发送了一封电子邮件，我被告知他们正在使用他们的解决方案他们自己提出了自己的想法，他们只透露自己正在使用“操作系统提供的安全功能”，并且“如果您知道如何使用操作系统[Linux]，它可以提供您所需的大部分安全性”。
有人知道如何安全可靠地执行此操作吗？我考虑过为每次提交生成一个新的虚拟机，但这会产生太多的开销，并且几乎不可能有效地实现。
I am looking into starting a project which involves executing python code that the user enters via a HTML form. I know this can be potentially lethal (exec), but I have seen it done successfully in at least one instance.
I sent an email off to the developers of the Python Challenge and I was told they are using a solution they came up with themselves, and they only let on that they are using "security features provided by the operating system" and that "the operating system [Linux] provides most of the security you need if you know how to use it."
Would anyone know how a safe and secure way to go about doing this? I thought about spawning a new VM for every submission, but that would have way too much overhead and be pert-near impossible to implement efficiently.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在现代 Linux 上，除了 chroot(2) 之外，您还可以使用 clone(2) 而不是 fork(2) 来进一步限制进程。有几个有趣的clone(2)标志：
以前这个功能是在OpenVZ中实现的，然后合并到上游，所以不再需要修补内核。
On a modern Linux in addition to chroot(2) you can restrict process further by using clone(2) instead of fork(2). There are several interesting clone(2) flags:
Previously this functionality was implemented in OpenVZ and merged then upstream, so there is no need for patched kernel anymore.
http://codepad.org/about 已经成功实现了这样一个系统（作为公共代码粘贴/运行服务） ！）
http://codepad.org/about has implemented such a system successfully (as a public code pasting/running service!)
如果您以用户
nobody（在 Linux 上）身份运行脚本，它几乎无法写入任何内容，也无法读取权限设置正确的数据。但它仍然可能导致 DoS 攻击，例如：/tmp此外，可以打开外部网络连接，等等。您可能可以通过内核限制锁定所有这些，但您肯定会忘记一些东西。
因此，我认为无法访问网络或真实硬盘驱动器的虚拟机将是唯一（合理）安全的途径。也许 Python 挑战赛的开发人员使用 KVM ，原则上，“由操作系统”。
为了提高效率，您可以在同一虚拟机中运行所有提交。这可以为您节省大量开销，并且在最坏的情况下，它们只会互相妨碍，但不会妨碍您的服务器。
If you run the script as user
nobody(on Linux), it can write practically nowhere and read no data that has its permissions set up properly. But it could still cause a DoS attack by, for example:/tmpFurthermore, outside network connections can be opened, etcetera etcetera. You can probably lock all these down with kernel limits, but you are bound to forget something.
So I think that a virtual machine with no access to the network or the real hard drive would be the only (reasonably) safe route. Perhaps the developers of the Python Challenge use KVM which is, in principle, "provided by the operating system".
For efficiency, you could run all submissions in the same VM. That saves you much overhead, and in the worst-case scenario they only hamper each other, but not your server.
使用
chroot(Wikipedia) 可能是解决方案的一部分，例如与ulimit和其他一些常见（或自定义）工具。Using
chroot(Wikipedia) may be part of the solution, e.g. combined withulimitand some other common (or custom) tools.