命名管道WCF安全問題

Question

我有一個稍微複雜的設置，當然，在XP中可以正常工作，但在Windows 7上可以窒息。它可能看起來很瘋狂，但它在當時有意義！

我有一個WPF應用程序啓動，然後啓動另一個應用程序與外部設備進行通信。啓動後，它使用WCF（由新進程託管）通過命名管道（net.pipe）與新進程建立通信。這似乎在任一操作系統上都能正常工作。我想讓WPF應用程序的某些功能在外部可用於命令行程序，所以我建立了另一個WCF服務，這次由WPF應用程序託管，並再次通過命名管道將其公開。再次，這似乎工作。

接下來，我想通過Web使WPF應用程序的功能可用。現在，WPF應用程序可以從普通用戶帳戶運行，這一點很重要，所以我認爲在Windows 7上完成這項工作的最佳方式是創建一個Windows服務，它將提供Web服務部分並將其傳回給WPF應用程序通過命令行工作正常的同一命名管道。我實現了這一點，它在XP上運行良好，但它在Windows 7上窒息。問題似乎與試圖建立Windows服務和WPF應用程序之間的命名管道連接。

如果我以管理員身份運行WPF應用程序，它工作正常。因此，運行Windows服務的帳戶似乎存在問題，無法與通過命名管道託管WCF服務的常規用戶帳戶進行通信。有沒有辦法做到這一點？看起來，在一個普通用戶帳戶中運行的WCF服務可以使用命名管道與另一個運行在同一個帳戶中的應用進行通信，但似乎它不能對另一個帳戶做同樣的事情。

奇怪的是，反過來似乎工作。事實上，Windows服務的確也暴露了一個帶有命名管道綁定的服務（因爲服務一直在運行，所以它被用作激活功能）。我可以從WPF應用程序連接到這個服務沒有任何問題。

我的安全知識有點有限。任何人都可以照亮發生的事情嗎？

Answer 1

這個問題以前曾在SO上提過幾次。例如，看到Connecting via named pipe from windows service to desktop app

的問題是，你的用戶會話的應用程序不具備必要的安全SeCreateGlobalPrivilege特權，讓他們創造在全球的內核命名空間其他會話可見的對象，但只能在本地命名空間是隻在會話中可見。另一方面，默認情況下使用此權限運行的服務可以這樣做。

它不是命名的管道對象本身，它以這種方式被侷限於本地命名空間，而是另一個命名的內核對象，一個共享內存節，WCF命名管道綁定依賴它來爲其客戶端發佈管道的實際名稱，這是每次啓動服務時都會更改的GUID。

您可以通過反轉角色來獲得此約束 - 使Windows服務應用程序成爲您的用戶會話應用程序連接的WCF服務。 Windows服務沒有問題將其服務發佈到會話中。並且這種方式連接起來更有意義，因爲Windows服務始終在運行，而您的會話及其應用程序在您登錄和註銷時進出。您需要使用雙工協定來定義服務，以便一旦建立連接，通過WCF服務進行的基本通信流程仍然可以按照您原先預期的相同方向進行。

Answer 2

應用程序（WPF /控制檯）正在創建本地作用域命名管道（當它們無法創建全局作用域管道時，默認情況下會發生這種情況）。我的猜測是他們可以相互溝通，因爲他們可以看到每個人都命名管道，因爲他們在同一個帳戶下運行。

windows服務具有更高的權限，因此可以爲客戶端應用程序創建一個全局範圍的命名管道。

您可以查看關於Christian Weyer's Blog的討論。