A small update: It looks better now. 1 out of 20 attempts fails with the issue above. But still not completely stable.

Indeed, this example allows insecure connections which contradicts with our earlier observations. I've made a quick test by setting UserName and GroupName to daemon in the plist. That did not affect the behavior. Insecure connections were still allowed. I have created a feedback about opting in ATS by launchd jobs. Sharing the number for your reference: FB9942862 I will investigate why ATS gets involved in our case. I can think of a few interesting details from the top of my head: our daemon is sandboxed. Could that change the behavior? our daemon binary has an Info.plist embedded into it. Could that make ATS look at it from bundle point of view? it performs POST requests. Could that a reason why ATS gets kicked in?

Huh. That's curious because this is not what's happening according to our testing (my last comment above). This is what I am currently observing when a process that runs in the daemon context tries to perform a POST request to a HTTP address. 2022-03-03 11:51:55.384 E daemonnamed[1467:2af9] [subsystem:category] Error occurred while trying to send data: Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo={NSUnderlyingError=0x7ffbadf0ddd0 Unknown macro: {Error Domain=kCFErrorDomainCFNetwork Code=-1022 "(null)"}, NSErrorFailingURLStringKey=http://concealed, NSErrorFailingURLKey=http://concealed, NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.} So if I read this message correctly, ATS is restricting it from performing a network request due to an insecure connection. If I restore the URL to its original form (HTTPS), then the request is successful. is the comment about not having ATS protection in daemon context is about it being limited in some other way? So it's not the same as for user apps?

a small update. Made a quick test by trying to make a network request to a http address from the daemon side. Got the following error log message: "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection". So it looks like ATS is indeed operational when the daemon is making a network request using URLSession. So the only confusing part was the description of circumstances under which ATS is expected to be enabled.

That's great news! We already subscribe to quite a wide range of events from Endpoint Security APIs including ES_EVENT_TYPE_AUTH_CLONE for file clone operations. But we are still planning to add ES_EVENT_TYPE_AUTH_COPYFILE support. But it just means that adding the support is not that critical to have as soon as Monterey is out as we initially thought. Thanks for your help and assistance (as always :) ) Regards, Arthur

Hello, Quinn! Thanks a lot for your assist on this. I was struggling a bit with connecting to an AFP server. For some reason, it was rejecting all my connection attempts and no solutions I found online helped me. But I tried connecting to a SMB server and duplicating the file on a remote SMB server and this produces the same copyfile sys call. So it was a success in the end. I also managed to verify that our es_client instance correctly identifies this new event when I duplicate a file on a remote SMB server and handles it accordingly. So looks like it's working as designed. Our biggest worry was that this a somewhat recently added event and as soon as Monterey is dropped, we will be missing events that we need to evaluate. But it does not look that way so far. As far as I can see, the use case for this sys call is pretty narrow, isn't it? Best regards, Arthur