How to trigger ES_EVENT_TYPE_AUTH_COPYFILE Endpoint Security event

Hello, We have an AV product for macOS that uses Endpoint Security APIs for authorizing various system activity. The latest Monterey beta 6 introduced support for an event called "ES_EVENT_TYPE_AUTH_COPYFILE" which according to the release notes should be triggered for "copyfile" system call.

The problem is I cannot seem to find any activity that actually ends up triggering this system call while using the latest Monterey beta.

  1. "/bin/cp" generates two open system calls
  2. More high level NSFileManager "copyItemAtPath:toPath:error:" generates a clone event
  3. There is a "copyfile" C function that is defined in "copyfile.h" also generates two separate open calls.

Did someone figure out how to trigger it or could someone from Apple give a comment? We'd usually ask such question via DTS ticket but it's about beta software so we decided to start her on the forum. Thanks.

Best regards, Arthur

Answered by DTS Engineer in 687896022

I suspect that this is triggered by the SYS_copyfile system call. This is a very obscure part of Mac file system lore…

Way back in the day — we’re talking mid 80s here, when we introduced the AppleShare server and its associated AFP network protocol — we wanted to allow clients to copy a file on a server without transferring all the data from the server to the client and back again. To support this we added an FPCopyFile command to AFP and the associated PBHCopyFileSync API to the File Manager [1]. This continues to be supported to this day [2]. So, if you mount an AFP volume and use Finder > File > Duplicate to copy a file on that server, you’ll see this:

% sudo fs_usage -f filesys | grep copyfile
…
10:39:19  copyfile          /Volumes/Fluffy/Other Stuff/test.txt                                             0.036000   DesktopServi
^C

The DesktopServicesHelper process — that is, the back end of the Finder — has made a SYS_copyfile call to copy the test.txt file.

Now, I don’t have time today to try this out in an ES client but I figured that you could do that at your end and let us known what you see (-:


I’m not sure how the Finder has actually triggered the SYS_copyfile system call. I very much doubt it’s calling PBHCopyFileSync, which was deprecated years ago (-: I suspect that it gets invoked automatically by the copy engine (either <copyfile.h> or NSFileManager) when the source and destination are on an AFP volume. However, I don’t have time to research that in the context of DevForums.


We'd usually ask such question via DTS ticket but it's about beta software

FYI, DTS has changed policy and now accepts tech support incidents related to seeded pre-release systems (with some caveats). I don’t think that’s necessary here, but it’s worth keeping in mind for the future.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] That’s the traditional macOS File Manager, declared in <Files.h>, not the Cocoa NSFileManager.

[2] I’m not sure if we ported it to SMB but it’s definitely still supported with AFP.

Accepted Answer

I suspect that this is triggered by the SYS_copyfile system call. This is a very obscure part of Mac file system lore…

Way back in the day — we’re talking mid 80s here, when we introduced the AppleShare server and its associated AFP network protocol — we wanted to allow clients to copy a file on a server without transferring all the data from the server to the client and back again. To support this we added an FPCopyFile command to AFP and the associated PBHCopyFileSync API to the File Manager [1]. This continues to be supported to this day [2]. So, if you mount an AFP volume and use Finder > File > Duplicate to copy a file on that server, you’ll see this:

% sudo fs_usage -f filesys | grep copyfile
…
10:39:19  copyfile          /Volumes/Fluffy/Other Stuff/test.txt                                             0.036000   DesktopServi
^C

The DesktopServicesHelper process — that is, the back end of the Finder — has made a SYS_copyfile call to copy the test.txt file.

Now, I don’t have time today to try this out in an ES client but I figured that you could do that at your end and let us known what you see (-:


I’m not sure how the Finder has actually triggered the SYS_copyfile system call. I very much doubt it’s calling PBHCopyFileSync, which was deprecated years ago (-: I suspect that it gets invoked automatically by the copy engine (either <copyfile.h> or NSFileManager) when the source and destination are on an AFP volume. However, I don’t have time to research that in the context of DevForums.


We'd usually ask such question via DTS ticket but it's about beta software

FYI, DTS has changed policy and now accepts tech support incidents related to seeded pre-release systems (with some caveats). I don’t think that’s necessary here, but it’s worth keeping in mind for the future.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] That’s the traditional macOS File Manager, declared in <Files.h>, not the Cocoa NSFileManager.

[2] I’m not sure if we ported it to SMB but it’s definitely still supported with AFP.

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

duplicating the file on a remote SMB server and this produces the same copyfile sys call

OK, so we did port it over to SMB. Cool.

As far as I can see, the use case for this sys call is pretty narrow, isn't it?

Yes. Notably, when we added an API for APFS’s copy-on-write feature, we didn’t use the copyfile system call but rather added something new (see the clonefile man page).

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

How to trigger ES_EVENT_TYPE_AUTH_COPYFILE Endpoint Security event
 
 
Q