如何在不泄漏句柄的情况下进行本地 IPC（跨平台）？

Question

如何在不让子进程继承所有句柄的情况下使用子进程启动 IPC？为了让它更有趣，这应该在 windows 和 unix 上工作。

背景：我正在编写一个与 3rparty 共享库（我们称之为 IT）接口的库，该库又包含全局数据（应该是对象！）。我想要这个全局数据的多个实例。据我了解，我有两种选择来解决这个问题：

1. 创建一个与 IT 的静态变体链接的 cython 模块，然后在我需要新实例时复制并导入该模块。类似地，我可以复制 IT，但创建 ctypes 接口的工作量更大。

2. 生成一个加载 IT 并建立到它的 IPC 连接的子进程。

使用（2）有几个原因：

• 我不确定，如果 (1) 以任何方式可靠，并且感觉是个坏主意（当应用程序以不受控制的方式退出时，所有额外的模块会发生什么情况？）。

• 出于安全考虑，将 IT 装箱到一个单独的流程中实际上可能是一个好主意：IT 处理潜在的不安全输入，并且 IT 的代码质量并不太好。所以，我宁愿在运行它时不要打开任何安全资源。

• 在未来的应用中可能会大量需要这种 IPC

那么我有哪些选择？我已经调查过了：

• multiprocessing.Process 起初看起来不错，直到我意识到新进程获取了我所有句柄的副本。不用说这是相当有问题的，因为现在无法通过在父进程中关闭资源来可靠地释放资源+前面提到的安全问题。

• 在 multiprocessing.Process 中使用 os.closerange 手动关闭所有句柄 - 除了我感兴趣的管道。os.closerange 是否只关闭文件或是否处理其他类型的资源好吧？如果是这样：给定Pipe 对象，我如何确定范围？

• subprocess.Popen(.., close_fds=True, stdin=PIPE, stdout=PIPE) 在 unix 上可以正常工作，但在 win32 上不行。

• 命名管道在 win32 和 unix 上非常不同。他们有没有他们使用的图书馆？

• 套接字。很有希望，特别是因为它们是可以使用套接字的方便的 RPC 库。另一方面，我担心这可能会导致一大堆安全问题。我确定为本地来源 (sock.getpeername()[0] == '127.0.0.1') 的套接字是否可以防止回火？

有没有我忽略的可能性？

总结一下：主要问题是如何在 windows+unix 上建立一个带有子进程的安全 IPC？但是，如果您只知道部分问题的答案，请不要犹豫。

感谢您抽出宝贵时间阅读！

Answer 1

似乎在 python>=3.4 subprocess.Popen(..., stdin=PIPE, stdout=PIPE, close_fds=False) 是一个可能的选择。这是由于一个补丁默认情况下使所有打开的文件描述符不可继承。更准确地说，它们会在execv 上自动关闭（所以仍然不能使用multiprocessing.Process），请参阅PEP 446。

这对于其他 python 版本也是一个有效的选项：

• 在 Windows 上，默认情况下创建的句柄是不可继承的，因此您只会泄漏显式可继承的句柄
• 在 POSIX/python

对应的例子见：

https://github.com/coldfix/python-ipc-test

最有用的组合是：

1. stdio:pickle

   • 专业人士：在我的测试中完全跨平台
   • 专业版： 最快的选项（有 2 个）
   • con: stdin/stdout 不能独立重定向

2. inherit_unidir:pickle

   • 专业人士：您可以独立重定向 STDIO 流
   • pro: 最快的选项连同 stdio:pickle
   • con：非常底层的平台特定代码

3. socket:sockpipe

   • 专业版： 轻松跨平台
   • 缺点：“攻击者”可能会在短时间内连接到端口，您可能需要密码或其他东西来防止这种情况发生
   • 缺点：比 Windows 上的替代品稍慢（我的测量结果为 1.6 倍）
   • 不使用 AF_UNIX 时，Linux 上的性能会出现不可预知的影响