我正在编写一个守护程序，该守护程序需要接受来自PID的来自潜在不受信任的应用程序的未命名管道连接。使用Unix域套接字，这不是一个复杂的任务：在文件系统上创建套接字，开始监听，接受传入的连接，通过辅助数据make sure that the application sending the file descriptor is what it pretends to be接收未命名管道的读取端的文件描述符（仅需要使用PID来找出其余部分，这很方便），然后开始使用私有的未命名管道连接从应用程序接收数据，同时仍在侦听套接字中的新连接。
但是，在Windows上，唯一可以被第三方应用程序识别的IPC方法（因此可以用于通过其他IPC方法建立连接而没有父子关系）被称为管道（在Unix中是已知的）术语作为FIFO文件）。多亏了DuplicateHandle()，无需使用某种辅助数据传输系统从应用程序获取文件描述符，只要目标进程知道该句柄的值，任何进程都可以将其任何句柄发送给任何其他进程。通过某种形式的IPC，在我的情况下，这是一个命名管道。但是，命名管道无法识别作者，即，如果应用程序在其中写入句柄x并假装具有某个PID a，则无法知道谁在该管道上的未命名管道上进行写入句柄x实际上是具有PID a而不是PID b的进程，试图破坏守护程序中的记录管理。
TL; DR如何在Windows上的守护进程和非子进程之间创建未命名的管道连接，并绝对确保该进程发送的管道句柄确实属于它而不是冒名顶替的进程？
答案 0 :(得分：0)
我决定完全不同地解决此问题，因为即使我知道另一个进程的PID（也可以通过查找该进程的.exe文件并读取该文件来确认另一个进程的身份）它的标头/与文件路径的匹配），我不确定该程序没有试图破坏守护程序，因为它可以发送任意句柄值，而不是创建管道并将真正的读取句柄发送给守护程序。最好的情况-守护程序优雅地拒绝连接，最坏的情况-它将崩溃或用不相关文件中的垃圾填充整个硬盘。对于系统范围的守护程序，这绝对是一个严重的问题。
要解决此问题，我改了两边。客户端发送一个初始化请求包（类似“你好，请在守护程序中注册我”），该守护程序使用GetNamedPipeClientProcessId所建议的this comment来获取PID并标识应用程序，然后创建DuplicateHandle伪句柄具有完全权限，因此使用GetCurrentProcess将句柄发送给客户端，然后将写入句柄发送给应用程序。这样，发送有效句柄的责任就在守护程序上，信任它的选择是针对客户端应用程序的，尤其是因为它是开源的，从而使希望使用该守护程序的应用程序开发人员可以确保它的安全性。从中接收句柄。