1

Windows 7 has a Session 0, where the services run, and the other sessions that interact with the users.

WCF clients running in Session 0 can't see pipes exposed in session 1 unless::

  • Set the SeCreateGlobalPrivilege - not an option for me
  • Show the UI running as a session 0 user but visible to the session 1 user - it's possible when the service starts the UI using CreateProcessAsUser
  • Use another binding, such as netTcpBinding

Any other solution?

This question is also featured on a Microsoft forum post

Jader Dias
  • 88,211
  • 155
  • 421
  • 625
  • 1
    More or less a duplicate of http://stackoverflow.com/questions/4303154/connecting-via-named-pipe-from-windows-service-session0-to-desktop-app-sessio – Chris Dickson Feb 10 '11 at 23:24

2 Answers2

1

Hardening... it got me too. I could not find a fix and had to change to TcpBinding.

Aliostad
  • 80,612
  • 21
  • 160
  • 208
  • The major drawback of this solution is that UAC will ask if the user wants to allow this, since it exposes one TCP port – Jader Dias Feb 10 '11 at 16:46
  • You are right but our app needed TCP for communicating outside as well so we had to deal with it anyway. – Aliostad Feb 10 '11 at 16:51
  • 1
    This is nothing to do with "named pipe hardening". It is all about the separation of kernel object namespaces (Global and Local) introduced in Vista... and it is the change this brought about for security on shared memory sections which causes the issue, not pipe security itself. Named pipes themselves are visible across sessions; but the shared memory used by NetNamedPipeBinding to publish the current pipe name is in Local namespace, not visible to other sessions, if the server is running as normal user without SeCreateGlobalPrivilege. – Chris Dickson Feb 10 '11 at 23:18
1

I was thinking in another solution: Inverting the roles and using a CallbackContract.

Jader Dias
  • 88,211
  • 155
  • 421
  • 625