runtime: Systemctl start service in Redhat with SElinux set to Enforcing fails

Edit by @antonfirsov : after resolving the dotnet-dump issue, new stack-trace here: https://github.com/dotnet/runtime/issues/56729#issuecomment-891641187

---

I have a dotnet core (3.1) worker service implemented as a systemd daemon in Redhat, SElinux enabled and set to Enforcing. Running systemctl start [myService] sometimes fails with systemd[1]: [myService]: Failed with result 'protocol' (taken from the output of journalctl -xe -u [myService]) systemctl status [myService] shows Active: activating (auto-restart) (Result: protocol) (it auto restarts every 30 seconds)

I managed to run a dotnet-dump on the executable process id this systemd executes (defined by ExecStart). The output is as follows:

Writing full to /home/redhat-build/Downloads/core_20210802_174944
Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (13): **Permission denied /tmp/dotnet-diagnostic-22279-705688-socket**
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) in /_/src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs:line 4296
   at System.Net.Sockets.Socket.Connect(EndPoint remoteEP) in /_/src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs:line 892
   at System.Net.Sockets.Socket.UnsafeBeginConnect(EndPoint remoteEP, AsyncCallback callback, Object state, Boolean flowContext) in /_/src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs:line 2151
   at System.Net.Sockets.Socket.BeginConnect(EndPoint remoteEP, AsyncCallback callback, Object state) in /_/src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs:line 2122
   at Microsoft.Diagnostics.NETCore.Client.IpcSocket.Connect(EndPoint remoteEP, TimeSpan timeout) in /_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcSocket.cs:line 50
   at Microsoft.Diagnostics.NETCore.Client.IpcUnixDomainSocket.Connect(EndPoint localEP, TimeSpan timeout) in /_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcUnixDomainSocket.cs:line 31
   at Microsoft.Diagnostics.NETCore.Client.IpcEndpointHelper.Connect(IpcEndpointConfig config, TimeSpan timeout) in /_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcTransport.cs:line 69
   at Microsoft.Diagnostics.NETCore.Client.PidIpcEndpoint.Connect(TimeSpan timeout) in /_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcTransport.cs:line 230
   at Microsoft.Diagnostics.NETCore.Client.IpcClient.SendMessage(IpcEndpoint endpoint, IpcMessage message) in /_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcClient.cs:line 25
   at Microsoft.Diagnostics.NETCore.Client.DiagnosticsClient.WriteDump(DumpType dumpType, String dumpPath, Boolean logDumpGeneration) in /_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsClient/DiagnosticsClient.cs:line 101
   at Microsoft.Diagnostics.Tools.Dump.Dumper.Collect(IConsole console, Int32 processId, String output, Boolean diag, DumpTypeOption type, String name) in /_/src/Tools/dotnet-dump/Dumper.cs:line 111
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) in /_/src/coreclr/src/System.Private.CoreLib/src/System/Reflection/RuntimeMethodInfo.cs:line 399
   at System.Delegate.DynamicInvokeImpl(Object[] args) in /_/src/coreclr/src/System.Private.CoreLib/src/System/Delegate.CoreCLR.cs:line 89
   at System.Delegate.DynamicInvoke(Object[] args) in /_/src/libraries/System.Private.CoreLib/src/System/Delegate.cs:line 64
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseErrorReporting>b__21_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass25_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass23_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__22_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseDirective>b__20_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseDebugDirective>b__11_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__10_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseExceptionHandler>b__0>d.MoveNext()

The dump shows an access denied at /tmp/dotnet-diagnostic…-socket I have seen SELinux issues with docker sockets before. Is this related ? Does the solution rely in declaring a SElinux permission policy that will allow access to this file ? What are the files, however, that are being accessed in starting a systemd daemon ?