Thanks Quinn!I will be opening a DTS Code Level support. But before that, I have few unknown questions that I would like to discuss so as to have more context regarding the problem before seeking DTS.When I use 0x7fffffff as an authorized_flags value for es_respond_flags_result(,,,) - It works perfectly with caching set to true. I found this flag as part of the thread opened by Bill_Chui (https://forums.developer.apple.com/thread/133635). Surprisingly, setting this authorized flag to 0x7fffffff (or INT_MAX) makes caching with ES_EVENT_TYPE_AUTH_OPEN work without a glitch! I have few queries around this:1. Is 0x7fffffff the correct flag that we need to set while responding to ES_EVENT_TYPE_AUTH_OPEN ?2. Afaik, setting authorized flag 0x7fffffff with es_respond_flags_result, typically means authorizing the file open events with all intended flags. In this case, if a user opens a file with Read-Only mode and ES client authorizes the file open event with 0x7fffffff and caching the event result - does it mean that ES client will grant the subsequent Read-Only file events will all set of permissible flags ?3. What is being cached here as part of event result - If I authorize a file open with 0x7fffffff, does ES subsystem cache all the subsequent events with 0x7fffffff ?I would like to get answers to these three queries before I raise a DTS so that I could have a better idea about the problem/unknows here. Which would also be helpful for Apple to understand what exactly I'm trying to achieve with my app.PS: I am working with SIP and AMFI disabled (sudo nvram boot-args="amfi_get_out_of_my_way=0x1”). I'm afraid I might hit the case which is mentioned here https://forums.developer.apple.com/thread/133635 after I test my app with SIP enabled and production signed. I wonder if I need to raise a separate DTS for this hang issue.

I assume you're only interested in "Move to Trash" and not deletion. "ES_EVENT_TYPE_AUTH_UNLINK" would get triggered if you use the "rm" command or Delete/Empty a file from Trash after it was moved. I don't know if I can be of any help here but following is the only answer I have off the top of my head:If I want to intercept events for "Move to Trash" operation, then I would probably use "ES_EVENT_TYPE_AUTH_CREATE" (https://developer.apple.com/documentation/endpointsecurity/es_event_type_t/es_event_type_auth_create?language=objc).After subscribing to "ES_EVENT_TYPE_AUTH_CREATE", I need to use "es_event_create_t (https://developer.apple.com/documentation/endpointsecurity/es_event_create_t?language=objc) to parse the "destination" path. For each destination path received, I would check if my path contains the string, "~/.Trash". If I find a path matching "~/.Trash", I would set "ES_AUTH_RESULT_DENY" else "ES_AUTH_RESULT_ALLOW". This is because a file can only be created in Trash if it was "Moved to Trash". In short, If you want to deny moving a specific file to trash, you might want to deny that specific file being created in Trash.However, I might be incorrect here and you would probably need to have your own set of rules implemented using the ES AUTH events.

I tried intercepting ES_EVENT_TYPE_AUTH_UNLINK events. It worked for me. One thing to note is that, if you use the Finder UI to delete files, you'll not get deletion events. What I mean is, if you right-click on the file and select "Move to Trash", the file doesn't get deleted. Instead, if you use the "rm" command for deletion, you'll see ES_EVENT_TYPE_AUTH_UNLINK event being processed. "Move to Trash" is basically moving the file to the folder "~/.Trash/" so that it could be recovered in future unless you delete the file ("Delete Immediately...") from Trash or "Empty Trash" (which is basically nothing but invoking "rm"). So, "/bin/rm" is actually the binary that would trigger the event ES_EVENT_TYPE_AUTH_UNLINK. And we could subscribe to this event type for authorizing the deletion of a file.For instance, here's my code:es_handler_block_t deletion_cbk = ^(es_client_t *client, const es_message_t *msg) { log_events(msg); //logging events to console NSString *path = esstring_to_nsstring(&msg->event.unlink.target->path); //casting es_string_token_t to NSString es_auth_result_t flag = ([path rangeOfString:@"dont_delete_me"].location == NSNotFound) ? ES_AUTH_RESULT_ALLOW : ES_AUTH_RESULT_DENY; // checking if the substring "dont_delete_me" is found in the event message es_respond_result_t res = es_respond_auth_result(client, msg, flag, false); if(ES_RESPOND_RESULT_SUCCESS != res) LOG_ERROR("es_respond_auth_result: %d", res); };After subscribing to ES_EVENT_TYPE_AUTH_UNLINK with es_new_client(), I am intercepting the file deletion event messages inside this es_handler_block_t callback. The esstring_to_nsstring() function (to cast es_string_token_t to NSString) implementation is similar to: https://gist.github.com/Omar-Ikram/8e6721d8e83a3da69b31d4c2612a68ba#file-endpointsecuritydemo-m-L47-L56OUTPUTUddalak:Desktop qwerty$ echo "this file should be deleted" > delete_me.txt Uddalak:Desktop qwerty$ echo "this file should not be deleted" > dont_delete_me.txt Uddalak:Desktop qwerty$ rm delete_me.txt Uddalak:Desktop qwerty$ rm dont_delete_me.txt rm: dont_delete_me.txt: Operation not permitted Uddalak:Desktop qwerty$ ls -ltrh | grep "dont" -rw-r--r-- 1 qwerty staff 32B May 28 15:01 dont_delete_me.txt Uddalak:Desktop qwerty$As you can see the file, "dont_delete_me.txt" doesn't get deleted as I set ES_AUTH_RESULT_DENY for files containing the substring "dont_delete_me". Additionally, once I had selected "Move to Trash" and then deleted the file ("Delete Immediately..." from the Trash) or "Empty Trash", then I was able to intercept the deletion event (like I said, which is basically nothing but invoking "rm").