在沙盒 Pypy 中使用套接字模块
我试图允许使用 Pypy 沙箱化的子进程使用有限的协议与父进程进行通信。
查看 Pypy 附带的 pypy/pypy/translator/sandbox/sandlib.py 的源代码后，似乎有一个 VirtualizedSocketProc 允许 os. open 调用打开套接字。我更改了代码的一些功能（例如，允许在有限端口上进行 TCP 连接），但几乎没有进行任何更改。但是，我无法实际导入 Pypy 的 socket 模块，因为它需要一个不存在的 _socket 模块，该模块似乎位于代码的解释器级部分。
我想做的事情可行吗？如果是这样，我如何导入套接字模块？如果没有，我还能做什么？
I'm attempting to allow a subprocess sandboxed with Pypy to communicate, using a limited protocol, with the parent process.
After reviewing the source code of the pypy/pypy/translator/sandbox/sandlib.py included with Pypy, it appears that there is a VirtualizedSocketProc that allows os.open calls to open sockets. I've changed some functionality of the code (for example, allowing TCP connections on limited ports), but very little has been changed. However, I'm unable to actually import Pypy's socket module because it requires a non-existent _socket module, which seems to be located in the interpreter-level parts of the code.
Is what I'm trying to do feasible? If so, how do I import the socket module? If not, what else can I do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我对此进行了进一步调查，看来这是一个相当基本的问题。
socket模块在库级别（在lib目录内部）实现，本质上是_socket库的一个空壳，它是在 pypy/module 目录中定义的解释器级模块。对于那些不熟悉 PyPy 的人来说，可以导入两种类型的模块，大致对应于 CPython 中的纯 Python 和 C 库。在库级别实现的模块可以轻松包含在沙箱中，并且实际上包含在“默认”pypy_interact沙箱中。但是，在解释器级别编写的模块在沙箱内不可用。由于这种关键的区别，我的方法似乎从根本上来说是有缺陷的。相反，如果遇到同样的问题，您可以考虑其他一些选项：
os.open以及以tcp://开头的文件名。这实际上非常有效，也是我最喜欢的方法。socket库。这当然不是优选的，但我相信可以创建一个相对空的套接字库，它只是与沙箱控制器通信，如上面包装套接字功能一样。甚至可以修改默认套接字库来实现此目的（例如，不包括_socket）。I've investigated this further, and it appears that this is a fairly fundamental problem. The
socketmodule, implemented at the library level (inside of thelibdirectories) is essentially an empty shell for the the_socketlibrary, which is an interpreter-level module defined in thepypy/moduledirectory. For those unfamiliar with PyPy, there are two types of modules that can be imported, roughly corresponding to the pure-Python and C libraries in CPython. Modules implemented at the library level can be included easily in the sandbox, and are in fact included in the "default"pypy_interactsandbox. However, modules written at the interpreter level are not available inside the sandbox.It seems that my approach was fundmanetaly flawed, because of this critical distinction. Instead, there are a few other options that you can consider, should you run into the same problem:
os.opendirectly with a filename beginning withtcp://. This actually works very well and is my favoured approach.socketlibrary. This is certainly not preferable, but I believe that it would be possible to create a relatively empty socket library that simply communicates with the sandbox controller as above wrapping the socket functionality. It might even be possible to modify the default socket library to achieve this (without including_socket, for example).