0

如何使用子进程启动 IPC,而不让它继承所有句柄?为了让它更有趣,这应该在 Windows 和 unix 上工作。

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

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

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

使用 (2) 有几个原因:

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

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

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

那么我的选择是什么?我已经研究过:

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

  • os.closerange在 a中使用multiprocessing.Process手动关闭所有句柄 - 除了我感兴趣的管道。是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?但是,如果您只知道部分问题的答案,请不要犹豫。

感谢您花时间阅读它!

4

1 回答 1

0

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

这也是其他 python 版本的有效选项:

  • 在 Windows 上,HANDLE 默认创建为不可继承的,因此您只会泄漏显式可继承的句柄
  • 在 POSIX/python<=3.3 上,您仍然可以使用 os.closerange 在生成子进程后关闭打开的文件描述符

有关相应示例,请参见:

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

最有用的组合是:

  1. 标准输入法:泡菜

    • pro:在我的测试中完全跨平台
    • pro:最快的选项(带 2 个)
    • 缺点: stdin/stdout 不能独立重定向
  2. 继承_unidir:泡菜

    • 亲:您可以独立重定向 STDIO 流
    • pro:最快的选项与 stdio:pickle
    • con:非常底层的平台特定代码
  3. 插座:袜子管

    • pro:跨平台,不费吹灰之力
    • 缺点: “攻击者”可能会在短时间内连接到端口,您可能需要密码或其他东西来防止这种情况发生
    • 缺点:比 Windows 上的替代品稍慢(我的测量结果为 1.6)
    • 当不使用 AF_UNIX 时,Linux 上会出现不可预知的性能影响
于 2014-01-29T14:31:40.020 回答