Interrupted system call error when we register for ES_EVENT_TYPE_AUTH_CREATE

Interrupt system calls are a fact of life on UNIX-y systems. Any system call that blocks can fail with EINTR and you must respond to that by retrying the call. If you’re making that system call it’s your responsibility to retry the call. If someone else is making the system call it’s their responsibility to do this.

So, which system call is failing in this way? And which code is making this call?

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

It fails to create a file , once we clone the git , git clones the files into .git from there it checkouts the working branch.
in this case git is not able to checkout the files

WE have the EPS client which has registered for "ES_EVENT_TYPE_AUTH_CREATE".

In fact we have also responded with "es_respond_auth_result". from the EPS client.

Mostly I am expecting the fwrite failed on the side of git , but with out the EPS the git clone is successful

I’m still not sure I understand what you’re saying here, so let me restate this for clarity:

• You have an endpoint security (ES) client that’s registered for ES_EVENT_TYPE_AUTH_CREATE.

• In this specific test your ES client is responding to the ES_EVENT_TYPE_AUTH_CREATE event by calling es_respond_auth_result with ES_AUTH_RESULT_ALLOW.

• When your client is active, git clone fails.

Is that right? If so, am I right in assuming that it prints the error Interrupted system call?

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

Yes this is what i meant.

OK. I’d probably classify that as a bug in git because open is documented to return EINTR and so git should handle that case by retrying the open. However, there are lots of apps that don’t handle this correctly, and so we need to investigate this some more.

Can your reproduce this with a minimal ES client? That is, if you create an ES client that only listens for the ES_EVENT_TYPE_AUTH_CREATE event and always allows that event, and does nothing else, does it still reproduce the problem?

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

Another developer opened a DTS tech support incident about this and that gave me a chance to dig into it further. In summary:

• This is a known issue in ES (r. 74618928).

• We believe it’s fixed in the current macOS 11.3rc.

Please install that release (or the final release once it’s available) and retest.

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