命名管道的 WCF 安全问题

Question

我有一个稍微复杂的设置，当然，它在 XP 中运行良好，但在 Windows 7 上却无法正常工作。这看起来很疯狂，但在当时是有道理的!

我有一个 WPF 应用程序启动，然后启动另一个与外部设备通信的应用程序。启动后，它使用 WCF(由新进程托管)通过命名管道 (net.pipe) 与新进程建立通信。这似乎在任何一个操作系统上都能正常工作。

我想让 WPF 应用程序的某些功能在外部可供命令行程序使用，因此我设置了另一个 WCF 服务，这次由 WPF 应用程序托管，并再次通过命名管道公开它。同样，这似乎有效。

接下来，我想通过 Web 提供 WPF 应用程序的功能。现在，重要的是 WPF 应用程序可以从普通用户帐户运行，所以我认为在 Windows 7 上进行这项工作的最佳方法是创建一个提供 Web 服务部分的 Windows 服务，并让它与通过适用于命令行的相同命名管道的 WPF 应用程序。我实现了它，它在 XP 上运行良好，但在 Windows 7 上却无法运行。问题似乎与尝试在 Windows 服务和 WPF 应用程序之间建立命名管道连接有关。

如果我以管理员身份运行 WPF 应用程序，它工作正常。因此，运行 Windows 服务的帐户似乎存在问题，无法与通过命名管道托管 WCF 服务的常规用户帐户进行通信。有没有办法使这项工作？在普通用户帐户中运行的 WCF 服务似乎可以使用命名管道与在同一帐户中运行的另一个应用程序进行通信，但它似乎无法通过不同的帐户执行相同的操作。

奇怪的是，反过来似乎也行得通。事实上，windows 服务也公开了一个带有命名管道绑定(bind)的服务(它被用作激活函数，因为该服务一直在运行)。我可以毫无问题地从 WPF 应用程序连接到此服务。

我的安全知识有限。任何人都可以阐明正在发生的事情吗？

Answer 1

这个问题之前已经在 SO 上被问过好几次了。例如，参见 Connecting via named pipe from windows service to desktop app

问题是您的用户 session 应用程序不拥有必要的 SeCreateGlobalPrivilege 安全权限，以允许它们在对其他 session 可见的全局内核 namespace 中创建对象，而只能在仅在 session 中可见的本地 namespace 中创建对象。另一方面，默认情况下使用此权限运行的服务可以这样做。

以这种方式约束到本地命名空间的不是命名管道对象本身，而是另一个命名内核对象，一个共享内存部分，WCF 命名管道绑定(bind)依赖于它以向其客户端发布实际的管道的名称，这是一个 GUID，每次启动服务时都会更改。

您可以通过颠倒角色来绕过此约束 - 将 Windows 服务应用程序设为 WCF 服务，您的用户 session 应用程序将连接到该服务。 Windows 服务将其服务发布到您的 session 没有问题。以这种方式连接起来更有意义，因为 Windows 服务始终在运行，而您的 session 及其应用程序会随着您的登录和注销而出现和消失。您需要使用双工协定定义服务，以便一旦建立连接，WCF 服务上的基本通信流仍然可以按照您最初预期的方向进行。