(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

Up vote post of ilowry Down vote post of ilowry
1.3k views
Posted by
ilowry
Reply

  • 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?

    —
    ilowry
Add a Comment

Accepted Reply

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"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

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"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

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

Posted by
ilowry
Up vote reply of ilowry Down vote reply of ilowry
Add a Comment

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"

Posted by
eskimo
Post not yet marked as solved Up vote reply of eskimo Down vote reply of eskimo

  • Thank you Quinn! If there's nothing I can do to fix it, I just take it as it is and calm down. :)

    —
    ilowry
Add a Comment