- 此问题在此处已有答案**：
AF_UNIX in windows（3个答案）
2天前关闭。
我正在编写一个守护进程，它需要接受来自潜在不可信应用程序的由PID标识的未命名管道连接。使用Unix域套接字，这不是一个复杂的任务：在文件系统上创建一个套接字，开始侦听，接受传入的连接，通过辅助数据make sure that the application sending the file descriptor is what it pretends to be接收未命名管道的读取端的文件描述符（只需要PID就可以计算出其余部分，这很方便），然后开始使用私有的未命名管道连接从应用程序接收数据，同时仍然侦听套接字是否有新的连接。
但是，在Windows上，第三方应用程序可以识别的唯一IPC方法（因此可以用于通过IPC的其他方法建立连接，而无需父子关系）命名为pipes（Unix术语中称为FIFO文件）。由于DuplicateHandle()，不需要使用某种辅助数据传输系统来从应用程序获得文件描述符任何进程都可以将其句柄中的任何句柄发送到任何其它进程，前提是目标进程通过某种形式的IPC知道句柄值，在我的例子中，IPC是一个命名管道。但是，命名管道不标识写入程序，即如果应用程序在那里写入句柄x并假装具有某个PID a，无法知道在句柄x上的未命名管道上写入数据的人实际上是PID为a而不是PID为b的进程，该进程试图扰乱守护进程中的记录管理。
TL; DR如何在Windows上创建守护进程和非子进程之间的未命名管道连接，并绝对确保该进程发送的管道句柄确实属于它而不是冒名顶替者进程？
2条答案
按热度按时间46scxncf1#
我决定完全不同地处理这个问题，因为即使我知道另一个进程的PID（这将允许我通过查找进程的
.exe文件并阅读其头文件/与其文件路径进行匹配来确认另一个进程的身份），我不相信该程序不会试图破坏守护进程，因为它可以发送任意的句柄值，而不是创建一个管道并发送真实的的阅读句柄给守护进程。最好的情况是-守护进程优雅地拒绝连接，最坏的情况-它崩溃或充满了整个硬盘驱动器的垃圾从一个不相关的文件。这绝对是一个严重的问题，一个系统范围的守护进程。为了解决这个问题，我交换了双方。客户端发送一个初始化请求包（类似于“Hello，please register me in the daemon”），守护进程使用
GetNamedPipeClientProcessId（如此注解所建议）来获取PID并标识应用程序，创建一个未命名管道并使用DuplicateHandle将句柄发送到客户端，这要归功于GetCurrentProcess伪句柄具有完全权限，然后将写句柄发送到应用程序。这样，发送有效句柄的责任就在守护进程上，而信任它的选择权则在客户端应用程序，特别是因为它是开源的，这使得希望使用守护进程的应用程序开发人员可以确保从守护进程接收句柄是安全的。tpxzln5u2#
今天这个问题的正确答案是Windows有一个类似于UDS的Unix域套接字，它们的使用方式与Unix相同。