为什么命名管道 WCF 服务拒绝 Windows 服务客户端？
在 Windows 7 和 .NET 4 上，当我的 WCF 客户端是 Windows 服务时，我会从 WCF 命名管道传输中获得一些非常奇怪的效果。
我的 WCF 服务托管在用户模式应用程序中，并通过命名管道绑定公开。
我的 WCF 客户端是一个 Windows 服务，作为网络服务运行（如果它作为本地系统运行，我会得到相同的结果）。
如果我的用户模式应用程序（即 WCF 服务）作为域管理员运行，则它可以正常工作，但如果用户模式应用程序是普通用户（或本地管理员），则连接将被拒绝并出现 CommunicationObjectFaultedException。
我在这里看到了一些与涉及 UAC 相关的问题，但我还没有在任何地方看到实际的解决方案，可以使命名管道传输正常工作。这只是一个不可避免的框架错误吗？
On Windows 7 and .NET 4 I'm getting some very weird effects from the WCF named pipe transport when my WCF client is a Windows service.
My WCF service is hosted in a user mode app and exposed over the named pipe binding.
My WCF client is a Windows service, running as Network Service (I get the same result if it runs as Local System).
If my user mode app (ie WCF service) is running as a domain admin then it works fine, but if the user mode app is an ordinary user (or local admin) then the connection is rejected with a CommunicationObjectFaultedException.
I saw some questions on here relating to UAC being involved, but I haven't seen an actual solution anywhere which just makes the named pipe transport work properly. Is this just an inescapable framework bug?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
来自 Christian Weyer 的博客条目 处理 WCF 命名管道场景中的操作系统权限“问题”：
因此，没有创建全局内核对象权限的进程打开的基于命名管道的通信机制（WCF 或其他）将无法从其自己的会话外部接收消息。
这似乎是意外后果法则的一个例子，对安全性的限制实际上会导致人们被迫使用网络可见传输而不是本地机器 IPC 机制，从而打开更多的安全漏洞。 MS确实应该为WCF提供适当的IPC通道，因为当前的命名管道传输不会切断它。
问题是，这并不是一个特别不寻常的场景，因为 .NET 服务想要与 .NET 托盘应用程序通信以提供用户通知。从托盘应用程序到服务的轮询机制将起作用......但轮询速度慢且资源密集，我想避免它。
有人知道更好的定制 IPC 传输吗？
蒂姆
From Christian Weyer's blog entry Dealing with OS privilege 'issues' in WCF Named Pipes scenarios:
So no named pipe based communication mechanism (WCF or otherwise) opened by a process without the privilege to create a global kernel object will ever be able to receive messages from outside its own session.
Seems to be that this is an example of the law of unintended consequences, where clamping down on security actually results in people opening more security loopholes by being forced to use network visible transports instead of a local machine IPC mechanism. MS should really provide a proper IPC channel for WCF because the current named pipe transport doesn't cut it.
Problem is that this isn't a particularly unusual scenario, for a .NET service to want to talk to a .NET tray app to provide user notifications. A polling mechanism from the tray app to the servide will work... but polling is slow and resource intensive and I'd like to have avoided it.
Anyone know of a better custom IPC transport?
Tim