I have the same problem (Xcode 12.3, MacOS 10.15 Catalina and 11.1 Big Sur). Our code (a security tool based on the new EndpointSecurity framework) attempts to extract some code-signing information for processes as part of logic that determines whether or not to authorize some user actions) So we execute CFDictionaryRef attributes = (bridge CFDictionaryRef)@{(bridge NSString *)kSecGuestAttributePid : [NSNumber numberWithInt:self.pid] }; SecCSFlags options = kSecCSDefaultFlags; status = SecCodeCopyGuestWithAttributes(NULL, attributes, options, &dynamicCode); and then do some verifications on the dynamicCode -- however, we're flooded with the same logs as the OP, plus, for some reason - despite the method returning success, OS hangs and kills our process immediately at that point (EndpointSecurity clients have this harsh reaction to just about anything, including any attempt to debug, or breakpoint, or run with instruments, or experience certain exceptions etc.). When run outside of the ES context - the code runs just fine, but logs are still emitted, for each execution of the SecCodeCopyGuestWithAttributes

Apple dev forum's usability and documentation is in par with the other parts of the OS and frameworks... that is... again I find myself disappointed. Anyway, Yet another hint about this issue (still unresolved, dear Eskimo - I would be so grateful for any ideas...) When my client is sandboxed - I get the "connection invalidation" handler called. when it's NOT sandboxed, I get the NSError 4097 trying to obtain the remoteObjectProxy from the connection. Go figure. The listener on my global daemon is never called for a new connection attemp (so my logs show) so I guess the connection attempt is blocked at the launchd level, or at some security stage - however, I just can't find anything in the logs, and I don't know how WHICH processes and frameworks are involved. The more I read documentation, the more I become confused - There seem to be .plist configurations For XPC Services (that are bundled as a "plugin" within an application) and whose entries may (or not?) be relevant to my case - but where and how would I stick those in my scenario? It's been almost 2 weeks of struggle already, and I don't know where to go next.

I saved and compared the output of launchctl print for both the working sample global-daemon and mine. They both look benign and identical, except for the expected differences (label of the daemon, path of executable, PID and port number of the endpoint). They also both have this environment = { XPC_SERVICE_NAME => com.mycompany.itm.service } entry, which says launchd KNOWS my global daemon should publish an XPC Service by this name. I managed to make another tiny progress, by trying to connect to my global daemon from the UI app of the sample-code I'm using - the one that succeeds in communicating with the sample daemon. I duplicated the code there, and try to talk to the two daemons - each with its own label and protocol. Now, the UI client app no longer calls my connection invalidation handler immediately as I try to get to the remote object proxy and send it a message, like thus:     id ro = [self.myServiceConnection remoteObjectProxyWithErrorHandler:^(NSError * _Nonnull error) {         NSLog(@"Error obtaining remote object: %@", error);  }];     if (myServiceRemote) {         [preventionRemote getStatus: ^(NSString * _Nonnull status) {  NSLog(@"Service status: %@", status);  }];     } I get this NSError. 2021-01-17 20:20:38.895040+0200 Client[18858:420994] Error obtaining remote object: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.mycompany.itm.service" UserInfo={NSDebugDescription=connection to service on pid 0 named com.mycompany.itm.service} Now what? I can't figure out how to debug this thing effectively - these are caveman's methods...

My daemon is up and running at all times, and is doing its work (some kind of monitoring and blocking of specific authorization events from EndpointSecurity framework). I started this endeavor with a working-order global daemon. My goal is to keep it small fast and safe, but still receive "control commands" from external process, and for that I want it to publish an XPC Service. Of course it does appear in the sudo launchctl list, and I can also launchctl print its state and properties without problem.

Have you found the solution? can you advise on how to do this? I'm trying this for days and days now, with very little success --- I have a sample code (from GitHub) that does this, but its daemon is not code-signed at all. When I try to apply this to my own global daemon - the client can't connect to it - its connection is invalidated, and I simply don't know what's wrong and what to don next. So can you spare your findings here, if you finally got it to work?

Dear eskimo, the launchd property list link is dead... could you please update it?

No one cared to answer, and I don't have an answer either - but in the mean time I received confirmation from Apple (I opened a tech-support-incident for this issue) that indeed this is a "Bug" or "unexpected behavior" of the operating system. No workaround was suggested by the tech-support engineers. My rather horrible work-around to this scenario is to "poll" by spawning a new instance of the same daemon executable (using NSTask) every few minutes, just so it can call the AXIsProcessTrustedWithOptions method, get a "fresh" and reliable answer and exit with return-code. If that answer is "NO", then I quit+relaunch the original process.

Hi, I'm jumping on this same cart, with the same error, only in my case I'm in even earlier stage of getting into Endpoint Security --- All I try to do is to build and run the related Apple Sample code as is! It's the "SampleEndpointApp" sample project. In my case, upon receiving from Apple the e-mail granting us the entitlement needed, I went on to create a development provisioning profile for this, and I'm trying to sign the app (and related System Extension) using that. The strange thing is - I see in the sample logs that the system extension was registered and installed - and I see lots of log lines that confirm that the system extension is actually being loaded from some place in the SIP protected parts of the OS. Only there's then an endless stream of error log lines for my App/Extension - nearly every 2-3 seconds another bunch of errors. About half of the error lines are coming from the Sandbox (similar to those the OP is complaining about) and the rest from the actual system extension - basically claiming: error 12:35:04.919059+0200 com.mycompany.mac.prevention.Extension Failed to open service: -536870174 error 12:35:04.919128+0200 com.mycompanty.mac.prevention.Extension Failed to create the ES client: 4 I really need a little light or guidance on this... I haven't even scratched the surface, and already stuck.

First off, many thanks!!! The sample clearly does what I (need but failed) to do. Sample is completely modern (SwiftUI, swift 5, MacOS SDK 10.16 etc.) whereas my app's code is all Obj-C, and must run on earlier MacOS versions then Catalina, so it seems I will have lots of work "decompiling" all modern stuff back to the basics I need to use. Will be back with questions, or "hooray!" style reports soon. B.T.W If you use SwiftUI, and programmed this on the Mac, how come you can't simply select the Mac target and test-run it? I'll do it of course (once I get to my office desktop running Catalina. My Mac is 10.14 + Xcode 11.5 on which the sample can't be built. The labs using my Microscopy App have older equipment, and must retain compatibility with old cameras, hardware connections, etc. So I can't always use "latest and greatest". Thanks again.

Hi, regarding the Process.run() mach port leak bug (BugReporter #46547156) -- are there any news? resolution? workaround? Was this issue resolved in Catalina? (we're at 10.15.5 already...) Also - could you kindly share here some of your debugging code (the library and hooks you described) that can help us investigate a similar problem we experience using NSTask? Thanks!

I think the iOS platform has shown that strict and granular permission-granting don't necessarily force horrific UI experience, and maybe adopting iOS-style design of your app can smooth this a little. Specifically, having multiple applications - can usually be replaced by having a single Application bundle, code-signed as one, but supporting several binaries, or "Privileged Helpers", or by itself launching Agents/Daemons in either user/system scope. If you build your software so - your user will only need to provide accessibility permission once. Also, there is a reason for restricting developers from introducing Kernel Extensions, which are the most common source of kernel panics, OS hangs and slowdowns, and bad energy management. It's not that Apple does not provide alternatives.In the special case of security/privacy permissions handling - MacOS indeed lags behind iOS, and to my humble opinion - the issue is more of bad documentation, than anything else. Obviously TCC database exists, and performs, since MacOS 10.8 - also, new "Lists" are added with every MacOS release (several were added in Catalina) so it's a living component of the OS. There is also a very important point to make here: Apple sees the end user's "last word" on privacy, as the top priority. not 'root' or 'admin' or 'corporate IT'. That's an on-going struggle. In my company, huge amount of MDM profiles, kernel extensions, amazingly-bad "support" applications, supervision agents and more - are installed on every corporate user's Mac - just to circumvent this. As a result, my 2020 MBPPro 16" takes 3 minutes!!! to boot, and eats up its battery in less than an hour. it also crashes, hangs, and requests reboot about 10 times a week. This is not my Mac's case - but all users' case. What I mean is -- Mac is a Personal computer. If you accept this - your software will usually work nicely. If you don't -- you'll probably end up with "Horrific UI" and weird solutions.