Launch daemon cannot read file on user's desktop

Hello,

I have a DLP product, which includes several components running as launch daemons with root privileges. When user send a file outside, the kernel extension will notify the scan engine to detect if the file has sensitive information. After installing 10.15.4 Supplemental Update, the launch daemons cannot read files even in user's desktop folder. And there is no permission request dialog at all. I need to grant file access to launch daemons manually in System Prerefences. Is this a new change in 10.15.4 Supplemental Update? There seems to be no problem for a root process to access any file on disk before. If this requirement is enforced, how can I prompt user to grant full disk access to background daemon during installation or its first launch? BTW, all the executable and dylibs in my product are already properly signed and notarized.

Thanks!

Replies

In previous versions of Catalina, my launchd daemon running as root seemed to be given full disk access implicitly by OS.

After installing recent update, my daemon still can access most file system locations except for user specific folders, like ~/Documents and ~/Desktop.

Yes. That's how it works.

I don't think that's how TCC works on earlier versions of Catalina. I don't need to grant full disk access to my daemon manually because it's not shown in the app list in System Preferences.

This change in recent update is all of a sudden and annoying. The OS fails to prompt users any dialog when my daemon tried to read some file on user's desktop which it does't have access to, probably because it cannot show any UI in root user context. I don't know.

I cannot find any API which I can use to check access rights and prompt users to enable them.

There is even no API which I can use to check if my daemon is in the "full disk access" list or not. If my daemon is not there, like in earlier version of Catalina, how can I ask users to grant access to it?

I don't think that's how TCC works on earlier versions of Catalina.

Why do you care how earlier versions used to work? This is how it works now, so you have to support it. End of story.


This change in recent update is all of a sudden and annoying.

You don't say.


The OS fails to prompt users any dialog when my daemon tried to read some file on user's desktop which it does't have access to, probably because it cannot show any UI in root user context.

That problem, at least, should be solvable.


I cannot find any API which I can use to check access rights and prompt users to enable them.

Nor will you.


There is even no API which I can use to check if my daemon is in the "full disk access" list or not.

You got that right.


If my daemon is not there, like in earlier version of Catalina, how can I ask users to grant access to it?

You might be over-thinking it. Have you tried to just manually putting your daemon in there with the "+" button. Forget for a minute about the user experience. Just try it. Does it work?


I ask this because I was using a root-level task for one particular job and found that it stopped working recently too. I think it is more than just having the app added to the Full Disk Access list. When the app is running in a different context, like a daemon or as a different user, it still doesn't work, even if it is in the Full Disk Access list. At least, that was my experience. Regardless, it was enough for me to just drop that feature altogether.


I don't know about your app, but I'm expected that a future macOS version will be the end of my app altogether. I'm working on something new that is more iOS-friendly.

Grant full disk access to /bin/bash.

Yep, as ridiculous as it sounds, that was it for my use case of running a script from launchctl.