Named Pipe Server throws UnauthorizedAccessException when creating a second instance if PipeSecurity is set

There are two things which can cause the instantiation of a second or subsequent
NamedPipeServerStream on the same pipe to fail:

  • the maxNumberOfServerInstances ctor argument must have been set to more than 1 when the first instance of the pipe server was created. If not, the second call will fail unless the first instance has already been closed completely.
  • the process calling the ctor must have the access right represented by PipeAccessRights.CreateNewInstance. This is a powerful right which the pipe server should guard jealously, as it allows its possessor the ability to act as a pipe server.

The service process should set the pipe security thus:

PipeSecurity ps = new PipeSecurity(); 
    ps.AddAccessRule(new PipeAccessRule(myPipeUsersGroup, PipeAccessRights.ReadWrite, AccessControlType.Allow)); 
    ps.AddAccessRule(new PipeAccessRule(myPipeServerIdentity, PipeAccessRights.FullControl, AccessControlType.Allow)); 

where:

  • myPipeUsersGroup is a placeholder for a group which contains all the prospective client identities which will connect to the pipe. Depending on your requirements/use case this might be a specific client identity, a custom group, or a built in group such as “Users” or “Administrators”.
  • myPipeServerIdentity is a placeholder for the service identity. This might be set, for example, to WindowsIdentity.GetCurrent().Owner. When the pipe server is hosted in a Windows service, then even better (but a good deal harder to implement) would be the Logon SID identity of the service process – this would ensure that only the specific service process could create instances of the pipe.

If you want to ensure that pipe access is restricted to just users logged on locally i.e. to prevent remote access across a network, you can also add a deny ACE for Network Users into the pipe security ACL.

Leave a Comment