Breaking changes to Full Disk Access in 11.4 Beta 3 ?

App & System Services Core OS
jerrykrinock OP
Created May ’21
Replies 11
Boosts 0
Views 4.9k
Participants 7
Ever since the update to macOS 11.4 Beta 3 two days ago, I have been going through hell trying to maintain Full Disk Access for my apps' background agents. I think something has changed with Full Disk Access, and I am very worried that the upcoming release of macOS 11.4 is going to break it for my users.

BACKGROUND

Because of open issues FB5929825 and FB7772296, my notarized macOS apps require Full Disk Access in order to access Safari bookmarks using a Apple private API. That works OK for the parent apps, but maintaining Full Disk Access for my apps' background agents has always been problematic.

Before Full Disk Access became a thing in macOS 10.15, my apps' background agent was a command-line tool, shipped within my apps' bundle, and launched intermittently by launchd tasks. Testing in early betas of 10.15, I could not find any way for a command-line tool to get Full Disk Access. (This may have been fixed in later versions.) Copying the design I saw in another app (Arq Backup) which had a working background agent, I spent several months replacing my command line tool with a Service Management Login Item which runs constantly. For brevity, I shall refer to my Service Management Login Item as "FooAgent".

Since then, users have been granting Full Disk Access to my apps after initially installing. The enclosed FooAgent apparently "inherited" Full Disk Access from the parent app, and all was well. I have never seen any documentation that this is by Apple's design, but it worked.

But, two days ago, upon restarting after the update to macOS 11.4 Beta 3, in addition to the fact that System Preferences' Full Disk Access checkboxes had been switched OFF for all non-Apple apps on my M1 MacBook Air (FB9103124), FooAgent emitted a warning that it did not have Full Disk Access, and this repeated even after I switched on the two checkboxes labelled "FooAgent" which had appeared in the Full Disk Access list and relaunched FooAgent. Through some combination of this action, removing a previous build of FooAgent, and restarting twice, I was able to restore Full Disk Access yesterday. But today, after rebuilding my app, which includes a rebuild of FooAgent, upon launching, FooAgent again reports no Full Disk Access, and today there are zero checkboxes for FooAgent in the Full Disk Access list. I beg someone from Apple to please answer for me:

  1. What is the correct, supported means by which a Service Management Login Item, contained within a parent app, can acquire and maintain Full Disk Access?

  2. Is it now necessary to re-grant, for testing, Full Disk Access after every build or update in the field? (Please, please say "No".)

  3. Is a Service Management Login Item which is contained within a parent bundle supposed to have its own entry and checkbox in System Preferences' Full Disk Access list?

BONUS QUESTION. Please, God, is there any chance that FB7772296 will be fixed in the next version of macOS, so I that can stop using Apple private API and stop requiring this Full Disk Access?

Replies  11
Boosts  0
Views  4.9k
Participants  7
webjib OP
May ’21
Big Sur 11.4 has been released, and I've got the same issue with one of my apps. This app includes an Helper Tool (a bundle), that is embedded in the LoginItems subfolder.

Before updating to 11.4, if user granted Full Disk Access to the main app, the Helper Tool got Full Disk Access too, as stated here by eskimo: https://developer.apple.com/forums/thread/107546

But now, it's not working anymore. The Helper Tool doe not inherit from the main app, either the Full Disk Access but also the authorisations like Automation for Finder.

Did someone find a solution to this?
2
jerrykrinock OP
May ’21
Not really a solution, but here is what happened. Before I begin, I'd like to say that, after my original post, I submitted FB9103124 to Apple on May 11, but there has been no response. Sadly, here we are. Support requests have begun to come in from my users also.

There are actually two issues.

  1. Full Disk Access is summarily disabled for all non-Apple apps which previously had it enabled.

  2. Helper Tool no longer inherits Full Disk Access from parent app.

Issue (1) is of course, just very annoying to users who must visit our web pages or email us to find what the @%*#! happened, and we need to apologize on behalf of Apple.

Issue (2) kind of went away by itself for me. It may have been that I had two useable versions of my app on my computer. After deleting one of them, and restarting a couple times, the remaining the FooAgent had Full Disk Access again, and eventually its inexplicable checkbox in System Preferences > Security & Privacy > Full Disk Access disappeared. I may have a few users with the more serious issue (2), so I'm just telling them to look for other versions, restart, etc.

Yes, it is a sad day here for the Mac.
2
webjib OP
May ’21
Thanks for you reply.

I've received 3 reports from users about the Full Disk Access issue (and also Automation inheritance that is broken). However, restarting the Mac did not fix the issue, and I'm testing the app on a different Mac, with only one copy of the app :(


1
jerrykrinock OP
May ’21
Well, on the support page which I created for users experiencing this issue, after explaining how to re-enable Full Disk Access, I said that if it still does not work for you, try throwing the kitchen sink at the Apple, as follows:

• Watch for our Agent in Activity Monitor by filtering on its process name.
• Command our parent app to switch off our Agent.
• If one or more of our Agent processes still appears in Activity Monitor, Quit or Force Quit.
• If our Agent process keeps reappearing, restart.
• Delete any other copies of our app.
• Verify that you've got zero of our Agent processes running.
• Quit our app if it is running.
• In System Preferences … Full Disk Access, switch the checkbox for our app OFF and then back ON.
• Launch our app, command it to start our Agent, and see if it has Full Disk Access now.

So far, one user who reported that simply re-enabling Full Disk Access did not fix this issue has said that subsequently throwing the kitchen sink at the Apple fixed it.
2
jerrykrinock OP
May ’21

At first, I thought that this issue was fixed in macOS 11.5 Beta, because my background agent was getting Full Disk Access without being listed in System Preferences' Full Disk Access list. But, then, and I don't know what I did other than build another new version of my app the other day with Xcode, my helper lost Full Disk Access. Actually, it is even worse than before, because now throwing the kitchen sink at the Apple does not fix it on my Mac.

Also, I have had two users report that throwing the kitchen sink at the Apple does not fix it for them, although, for dozens of users, either just re-enabling Full Disk Access for the parent app, throwing the kitchen sink at the Apple does seem to fix the problem. Mercifully, so far, my computer is the only one which has reportedly had the issue recur after it was "fixed". But I can imagine all hell breaking loose worse this time if Apple releases macOS 11.5 without fixing this, or at least telling developers what they need to change in their apps to make them work again.

2
jerrykrinock OP
May ’21

I forgot to mention that I filed a second Feedback Bug with Apple. To summarize:

FB9103124, May 11: macOS Big Sur 11.4 Beta 3 killed Full Disk Access for all non-Apple apps

FB9120467, May 27: macOS 11.4 broke more than just switching off Full Disk Access (and the trouble continues with macOS 11.5)

1
Thomas Tempelmann OP
Jun ’21

Just to add some clarification: Apps that run their helper tools via NSTask seem not be affected. At least my app Find Any File remains able to launch its "searchfs" helper this way, which in turn searches entire volumes, once the main app has gotten FDA, even in 11.4.

I suspect that the issue is only with helpers that get run outside of the main app's runtime, e.g. as launchd service, Login Item etc.

This change was apparently implemented to deal with CVE-2021-30713: (see https://mjtsai.com/blog/2021/06/01/macos-11-4-breaks-full-disk-access-for-helper-tools/#comment-3465367). But in a wrong way: Instead of making sure that embedded helpers are tested to belong to the main app, i.e. have the same codesign Team ID, it simply denies them FDA altogether if they're launched not directly by the main app, it seems. Looks like a hasty fix that was not well thought through. And bug reports about it then being ignored as well. Scary.

1
Thomas Tempelmann OP
Jun ’21

Just to double check: Your helpers are signed with the same cert as the main app is, right?

2
DTS Engineer OP
Apple
Jun ’21

Folks, I would love to dig into this in more depth but I don’t have time to do that right now (what with WWDC looming an’ all). Some advice:

  • WWDC is next week and it’s very likely that there will be labs that cover TCC (the lab schedule hasn’t yet been published but TCC generally falls under the security and privacy categories). If you’re having file system TCC problems, request a lab slot to talk with a team member about these issues one-on-one. WWDC labs are the perfect place to discuss issues like this because, sure, there’s a specific 11.4 change that’s the subject of this thread, but that’s just one part of the overall issue of how file system TCC impacts on various classes of non-app products.

  • With regards the specific 11.4 change, that’s something that I could look into officially via a DTS tech support incident. However, there’s no point opening that now because there’s no way I (or my colleague Kevin, who’s also involved in file system TCC stuff) will have time to investigate it properly this week. Rather, you should do the lab thing and then come back to this after WWDC.

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

1
cbfiddle OP
Aug ’21

Did the problem of non-Apple applications losing Full Disk Access get fixed in the 11.4 release? I just noticed that an application of mine that previously had Full Disk Access somehow lost it, and I'm not aware of installing the beta on this particular system. The application got an error trying to access a file in a subdirectory under ~/Library/Autosave Information. If the application did not have an entry in the Full Disk Access list of applications, would a dialog have been displayed? That would be better than my application showing its own dialog that attempts to explain the problem and the remedy.

0
bobbybugsplat OP
May ’22

We are also randomly losing Full Disk Access (on reboot?). Would love to see a fix here!

0
Breaking changes to Full Disk Access in 11.4 Beta 3 ?
First post date Last post date
 
 
Q