(EndpointSecurity) Task has not been granted user permission to connect

Hi all! I'm writing an enpoint security daemon, which is packed in an application bundle with embedded.provisionfile in its Contents folder.

This daemon can be successfully loaded and started with launchctl on Big Sur with SIP disabled, but fails to run when SIP is enabled. The os log from kernel contains the following messages:

(Sandbox) sandboxd rejected approval request from esservice for kTCCServiceSystemPolicyAllFiles(null): denied
(EndpointSecurity) Task has not been granted user permission to connect

Could anybody please explain me what could be the reason for this kind of messages? Is it a sign that something wrong with my provision profile file or something else?

Thanks in advance, Aleksandr

Answered by DTS Engineer in 688455022

The os log from kernel contains the following messages

FYI, when you register a new client you get back a es_new_client_result_t value, and in this case you should get back ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED, which is documented as:

This error indicates the app lacks Transparency, Consent, and Control (TCC) approval from the user.

You definitely want to pay attention to errors like this.

You wrote:

it looks like my daemon needs Full Disk Access

Correct.

The question is why the app, which is a wrapper around endpoint service daemon, requires that access?

I’m not sure I understand your question. When you say “app” are you referring to your daemon that’s been placed in an app-like package? Or do you have some other app in play here?

Share and Enjoy

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

Hmm, it looks like my daemon needs Full Disk Access, because it runs successfully, if I allow it Full Disk Access in System Preferences. The question is why the app, which is a wrapper around endpoint service daemon, requires that access? And how does the system know it needs it?

Accepted Answer

The os log from kernel contains the following messages

FYI, when you register a new client you get back a es_new_client_result_t value, and in this case you should get back ES_NEW_CLIENT_RESULT_ERR_NOT_PERMITTED, which is documented as:

This error indicates the app lacks Transparency, Consent, and Control (TCC) approval from the user.

You definitely want to pay attention to errors like this.

You wrote:

it looks like my daemon needs Full Disk Access

Correct.

The question is why the app, which is a wrapper around endpoint service daemon, requires that access?

I’m not sure I understand your question. When you say “app” are you referring to your daemon that’s been placed in an app-like package? Or do you have some other app in play here?

Share and Enjoy

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

Hi Quinn!

I’m not sure I understand your question. When you say “app” are you referring to your daemon that’s been placed in an app-like package? Or do you have some other app in play here?

It is the first one. I'm referring the daemon placed in the app-like package. I'm wondering, how the macOS knows my daemon needs such the access? Can it be because I use some DiskArbitration API calls to get information about the disk when handling the ES events?

Thanks, Aleksandr

how the macOS knows my daemon needs such the access?

Because it’s calling the ES client API and all ES clients are required to have Full Disk Access. There’s nothing you’re doing to trigger this, it’s just a blanket requirement.

Share and Enjoy

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

(EndpointSecurity) Task has not been granted user permission to connect
 
 
Q