runtime: System.IO.Pipes.AccessControl package does not work

Hello. Recently I encountered the same problem when translating the project to .Net Core. I added a nuget package to help with the transition: https://www.nuget.org/packages/NamedPipeServerStream.NetFrameworkVersion/ The package targets .Net Standard 2.0 and contains the original constructor from the .Net Framework (which supports PipeSecurity, HandleInheritability, and PipeAccessRights). I restored it from decompiled code without making any changes. Exceptions are fully supported, no code has been lost. Has a strong name. The source code is also available.

@JeremyKuhne It looks like this has been implemented but isn’t targeted for release until .NET 5.0 - a year from now. Is there any chance we can get an update to the System.IO.Pipes.AccessControl library that makes this work today?

I have a use case which requires more than just CurrentUserOnly. I have a program split into a local front end and local back end. The program uses named pipes for its IPC.

The problem is that the back end (which is a service) needs to run as an elevated user (i.e. Local System) but the front end only needs to run as the currently logged in user. So, I need some way to set access control to allow non-elevated clients to access the back end.

I have been using .NET Framework up until now for this project, but I’m trying to port bits and pieces of it to .NET Standard in order to make the project cross-platform.

What I know to do is create a .NET Framework project that abstracts the Windows implementation details away from the common functionality. Is there any other workaround that doesn’t involve .NET Full?

Seconding @TonyValenti’s comment - porting a critical piece of our previously .NET 4.7.1 app to .NET Core 3.1 this is a blocker.

If there’s not an official back port - I’ll probably end up doing a cherry-picked merge and crank out a local System.IO.Pipes.AccessControl NuGet package and host it in my Artifactory repo.

Hey, just to make sure I understood the current situation correctly. My use case looks like the one of @kfreezen.

• It’s currently just usable for two processes running under the same User?
• There is currently no way to configure Access-Rules or Permissions on non-Windows OSes?

@kfreezen Did you find a solution for this? I’m trying to do the same but don’t get any further than the UnauthorizedAccessException, too.

_pipeStream = new NamedPipeServerStream(PipeName, PipeDirection.In);

PipeSecurity pipeSecurity = _pipeStream.GetAccessControl();
pipeSecurity.AddAccessRule(new PipeAccessRule(new SecurityIdentifier(WellKnownSidType.AuthenticatedUserSid, domainSid: null), PipeAccessRights.ReadWrite, AccessControlType.Allow));
_pipeStream.SetAccessControl(pipeSecurity);

The NamedPipeServerStream is created inside of a .Net Core Windows-Service and a NamedPipeClientStream should be used by an application running in the user session to communicate to that service.

I ended up using a socket TCP stream for client-server communication on macOS and then using .NET Framework rather than .NET Core for the Windows portion of the project.

@pjanotti Is there currently a way to do cross-privilege message passing with .NET Core?

@pjanotti The PipeSecurity instance is being created by https://github.com/cloudveiltech/Filter-Windows/blob/d159989ed0385d5609372cbf690c23d43e51acec/Citadel.IPC.Common/IPC/IPCServer.cs#L679

That is being consumed by https://github.com/cloudveiltech/Filter-Windows/blob/d159989ed0385d5609372cbf690c23d43e51acec/Citadel.IPC.Common/IPC/IPCServer.cs#L288