On Windows 7 and .NET 4, there is some very strange effect on the name of the Pipe Transport by name WCF when my WCF Client One Windows Service
My WCF service is hosted in a user mode app and has been notified about named pipes binding.
My WCF client is a Windows service, which is working as a network service (I
if my user mode app (i.e., the WCF service) is running as a domain administrator , But if the user mode app is a normal user (or local administrator) then the connection has been rejected with a communication objectfolded exception.
I have some questions related to the UAC here But I have not seen the actual solution anywhere, from which only designated pipes transport work properly. Is this just an indispensable framework bug?
From Christian Wear's blog entry:
If my WCF server process uses a named pipe-based endpoint, a global kernel object If you do not have the privilege to create, then it fails silently.
Any named pipe-based communication system (WCF or otherwise) has the privilege of creating any global kernel object Without a process will be opened, will be able to receive messages outside of their own session anytime.
It seems that this is an example of the law of unexpected results, where falling on safety actually causes more security deficiencies than people being forced to use network visible transport instead of local machine IPC system. Are there. MS should actually provide a proper IPC channel for the WCF because the current designated pipe transport does not cut it.
The problem is that this is not a particularly unusual scenario, because talking to a .NET service is to provide user notifications in a .NET tray app. A voting system will work for servicing from the tray app ... but the polls are slow and deep in resources and I want to avoid it.
Does anyone find a better custom IPC transport?
Tim
Comments
Post a Comment