wcf - 为什么命名管道 WCF 服务拒绝 Windows 服务客户端？

Question

在 Windows 7 和 .NET 4 上，当我的 WCF 客户端是 Windows 服务时，我从 WCF 命名管道传输中得到了一些非常奇怪的效果。

我的 WCF 服务托管在用户模式应用程序中，并通过命名管道绑定(bind)公开。

我的 WCF 客户端是一个 Windows 服务，作为网络服务运行(如果它作为本地系统运行，我会得到相同的结果)。

如果我的用户模式应用程序(即 WCF 服务)作为域管理员运行，那么它工作正常，但如果用户模式应用程序是普通用户(或本地管理员)，则连接被拒绝并出现 CommunicationObjectFaultedException。

我在这里看到了一些与 UAC 有关的问题，但我还没有看到任何地方的实际解决方案，它只是使命名管道传输正常工作。这只是一个不可避免的框架错误吗？

Answer 1

来自 Christian Weyer 的博客文章 Dealing with OS privilege 'issues' in WCF Named Pipes scenarios :

If my WCF server process using a Named Pipe-based endpoint doesn't have privileges to create a Global kernel object it silently fails and creates a local one which will not be visible to processes outside of its session.

因此，没有权限创建全局内核对象的进程打开的任何基于命名管道的通信机制(WCF 或其他)都无法从其自己的 session 之外接收消息。

似乎这是意外后果定律的一个例子，在这种情况下，压制安全实际上会导致人们被迫使用网络可见传输而不是本地机器 IPC 机制来打开更多安全漏洞。 MS 应该真正为 WCF 提供适当的 IPC channel ，因为当前的命名管道传输并没有削减它。

问题是这并不是一个特别不寻常的场景，因为 .NET 服务想要与 .NET 托盘应用程序对话以提供用户通知。从托盘应用程序到服务端的轮询机制将起作用......但轮询速度很慢且资源密集，我想避免它。

有人知道更好的自定义 IPC 传输吗？

蒂姆