Closed ccruden-shookiot closed 4 years ago
Specifically this is a problem when the client is using the .NET Framework version of the library and running as user X, while the server is using the .NET Core version of the library and running as user Y.
I'd be happy to accept a PR that adds support for this with conditionally compiled options.
Ironically, the modifications were easy enough but it turns out the package itself doesn't work. (https://github.com/dotnet/runtime/issues/26869) Looks like they have something that should work for .NET 5 when it comes out - I'll give it another try then and see what happens.
I've got a changeset that would add support for pipe security in .NET 5.0 (and compile a version of the library for .NET 5.0, add a couple tests to make sure pipe security is working, etc.) but Github doesn't seem to want to let me create a pull request (error 403). I admit I haven't created a pull request for a public project before, so I may be doing something wrong, but do I need particular permissions in order to be able to do this?
You need to create fork of this repository under your account ("Fork" button), push your changes (to master or a branch), and then from your fork in Github you should have a prompt to create a PR here.
Thanks for the explanation! PR up. Not sure what I should do about the fail on the one flaky test....
Thanks for the PR! Added in version 1.3.0.
.NET Core 3.0 and 3.1 include PipeSecurity options that can be set on named pipes through PipesAclExtensions.SetAccessControl. This project seems to have settled on .NET Core 2.2 for some reason, which eliminates the possibility for setting ACL on the named pipes that it creates. (Causes a problem when, for instance, one end of the named pipe is running as one user and the other as a different one.) Given that .NET Core 3.1 is the LTS version that MS seem to have settle on, any chance of this project supporting Core 3.1 and those extensions?