IIS 下的 Windows 命名管道 ACL
我正在尝试使用命名管道将 CGI 进程连接到我的 Windows 服务。 我的代码在我的开发计算机上使用另一台服务器运行良好，但在 IIS 上，当我在 CGI 进程中调用 CreateFile() 时，会出现安全问题。
Windows 服务是命名管道服务器，因此 CGI 进程尝试作为客户端连接到该命名管道。
我挖出了一些代码，通过调用以下命令创建带有 SECURITY_WORLD_SID_AUTHORITY 标志的全局安全描述符：
InitializeAcl()
AddAccessAllowedAce()
SetSecurityDescriptorDacl()
但我并不真正理解这个概念。 我假设必须使用 SECURITY_ATTRIBUTES 结构中的此 ACL 来调用管道服务器 CreateNamedPipe()，但是命名管道客户端又如何呢？
我是否创建另一个全局安全描述符并用它调用 CreateFile() ？
我是否继承它，
SecurityAttributes.bInheritHandle = TRUE;
是否仅在 CreateFile() 调用中传递 Null？
I am trying to connect a CGI process to my windows service with a named pipe.
My code runs fine using another server on my development machine, but on IIS there are security issues when I call CreateFile() in the CGI process.
The Windows service is the Named Pipe Server and so the CGI process is trying to connect to that named pipe as a client.
I have dug up some code that creates a Global security descriptor with the flag SECURITY_WORLD_SID_AUTHORITY by calling:
InitializeAcl()
AddAccessAllowedAce()
SetSecurityDescriptorDacl()
But I dont really understand the concept.
I am assuming that the Pipe Server CreateNamedPipe() must be called with this ACL in the SECURITY_ATTRIBUTES structure but what about the Named Pipe client?
Do I create another Global security descriptor and call CreateFile() with that?
Do I inherit it with
SecurityAttributes.bInheritHandle = TRUE;
Do I just pass Null in the CreateFile() call?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于管道是由服务器创建的，因此仅服务器需要指定ACL，客户端使用ACL NULL。
仅当命名管道是在一个进程中创建的，并且该进程创建了一个新进程，您希望该生成的进程能够直接访问句柄时，继承才适用（它不会重新打开句柄，而是以其他方式获取值） ，就像命令行一样）。
您可以使用 sysinternals 上的 Process Explorer 查看在以下位置打开的命名管道一个进程然后看ACL。
Since the pipe is created by the server, only the server needs to specify the ACL, the client uses NULL for the ACL.
Inheritance only applies if the named pipe is created in one process and that processes creates a new process in which you want that spawned process to have direct access to the handle (it doesn't reopen the handle, rather it gets the value some other way, like a command line).
You can use the Process Explorer on sysinternals to view named pipes open in a process and then look at the ACL.