Reliable test for Full Disk Access?

I try to read from "/Library/Preferences/com.apple.TimeMachine.plist". If I get valid property list data, then I assume I have Full Disk Access. In my case, this is the information I need to read. It isn't even sensitive information. It is just in the wrong directory.

Is your app in the Mac App Store? If not, then no problem. I suggest opening this URL: "x-apple.systempreferences:com.apple.preference.security?Privacy_AllFiles". It will open the Prefernces page right to the appropriate value. You still have to tell the user about the "+" button. Many people don't know how to work the dialog.

However, if your app is in the Mac App Store, this will be an automatic rejection. You can have Full Disk Access, but it has to be hidden away somewhere and your app has to run, in some fashion, without it.

Anyway, is there any API or a more reliable test to see if my app has been added to the "Full Disk Access" list in System Preferences?

No. I recommend against the approach you’re using because the location and permissions of the TCC database is not considered API.

A better option is to do what you’re really trying to do and then handle errors accordingly. It’s hard to give specific recommendation without knowing more about the nature of your app. Can you explain more about the big picture here?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hello,

I came across this thread having the same question. I can provide a specific example with my app (Nightlight, in the App Store).

My application is a viewer for a particular kind of data file. Upon launch I start a Spotlight search to find all such files on the user's system. Spotlight tells me the path and filename, but of course I initially don't have read access to any of them, which is fine. Included in this search are files that are email attachments, which has been very useful. Up to 10.13, if the user wanted to view the file I'd request permission, get the sandbox bookmark, and things are fine.

In 10.14, any file in one of the new protected spaces (e.g. ~/Mail) still cannot be read. This is also fine; I just need to adjust my UI accordingly. If the user wants to see the file, I need to tell them about "Full Disk Access" in the Privacy tab in "Security & Privacy" to enable this. If "Full Disk Access" is already enabled for my app, I don't need to tell them about it in the UI. Of course, the user can enable or disable this access at any time (between application restarts). It would be helpful to know whether I have this access at a given time to know what to display to the user.

As I've seen advised before, I could just try to open the file and handle it then. I do this: I ask the user for permission to read the file through PowerBox, get it, but then I still can't read the file becuase it's in ~/Mail without "Full Disk Access".

I need a more bulletproof test for "do I have permission to read this file?". With 10.14, the quesion now becomes: "do I have or is it even possible for me to get permission to read this file?" I don't want to test if the file is in a specific directory as that list can change between OS releases. Having a test for "Full Disk Access" would help me better inform users how to view the file they are requesting.

Cheers,

Demitri

I agree with Demitr, I find it's a little backward approach to not have a robust way to test for FDA and instead handle errors resulting from the lack thereof. The problem is that sometimes you can't distinguish errors resulting from the lack of FDA and other kinds of errors. Or you have a lengthy operation that you know will fail or will be incomplete without FDA and you want to tell the user in advance.

In my case, my app estimates size of a directory. Some subdirectories inside of it will not be counted due to the lack of FDA, and the overall size will not match Finder's estimation. The scope of all folders protected from FDA is not clearly defined in the documentation, so I will not be able to detect when I have a lack of FDA or it's a different kind of error. I can guess and recommend the user to add my app to FDA, but it's confusing if he's already done that and still sees the recommendation. What should I do in these circumstances?

I wouldn't worry too much about trying to match the Finder's estimations. When it comes to sizes on disk, the Finder can be wildly inaccurate at times. I understand your concerns about wanting to be as accurate as possible. But you are never going to be able to match the Finder because that would require you to reverse engineer and re-implement all the bugs in Spotlight. That would be a lot of work. 😁

It should be pretty easy to identify the scope of folders protected by Full Disk Access. A simple Terminal script in a VM can do it. Eskimo is correct about this not being an API and changing from release to release. However, this caution applies to every aspect of the operating system, including officially supported APIs. I strongly urge a full test of app features in each beta, no matter how small and seemingly minor. At that point, you are (or should be) doing this testing anyway, so just make sure to give a little extra attention for any area like this where you diverge from Apple's official recommendations.

Also, you aren't going to be able to avoid user confusion regardless of what you do. This is just really confusing for users. Furthermore, Full Disk Access isn't very reliable either. You can do everything right and it still doesn't work sometimes. You have to budget for this and provide documentation on how to remove an app, restart, re-add, and fallback to tccutil in the Terminal when all else fails.

In theory, of course, Apple could provide a handy API for Full Disk Access. But realistically, that is never going to happen. And even if it did happen, the API would only be available in 10.15, where it would likely to be accompanied by even more restrictions.

The problem is that sometimes you can't distinguish errors resulting from the lack of FDA and other kinds of errors.

Right, and I think it’s reasonable to file an enhancement request for a way to distinguish different types of permission errors [1]. Right now the list of such errors is getting quite long (FDA, Data Vaults, SIP, sandboxing, ACLs, UNIX permissions), making it hard to give meaningful guidance to the user in the case of a permissions error.

The scope of all folders protected from FDA is not clearly defined in the documentation …

Right, and this is a key point. The scope of FDA is likely to change over time but, even if it doesn’t, we have Data Vaults, where requesting FDA won’t help. And it’s not hard to imagine more of this stuff coming down the pike.

In my case, my app estimates size of a directory.

I know this is off topic, but how do you handle APFS copy on write?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] If you do file any bugs, I’d appreciate you posting their numbers here, just for the record.

Can you elaborate on what a "Data Vault" is and where a developer would be likely to encounter one?

Can you elaborate on what a "Data Vault" is and where a developer would be likely to encounter one?

A Data Vault is a directory that’s only readable by a process that has a specific entitlement. So, for example, being root won’t give you access, nor will enabling FDA.

Data Vaults were introduced in the late 10.13.x releases [1].

Currently Data Vaults are completely private to Apple, meaning that there’s:

• No way to create one for yourself

• No way to access the content of an Apple one

• No documentation about the structure of a Data Vault

• No way to reliably identify a directory as a Data Vault [2]

• No official list of existing Data Vaults

One consequence of this is that a third-party backup product will not be able to back up a Data Vault [3]. In most cases this isn’t a problem because the contents will be transitory (caches, and other stuff that can be rebuilt if needed), and hence the Data Vault will be located in a directory that isn’t backed up anyway.

IMPORTANT The following is meant as an example only. As I mentioned above, the structure of a Data Vault is not publicly documented.

For example, consider this:

$ ls  $TMPDIR../0/ | cat
…
com.apple.nsurlsessiond
…

So the temporary directory has an item called

com.apple.nsurlsessiond

$ stat $TMPDIR../0/com.apple.nsurlsessiond
stat: /var/folders/7j/6bzgmchs7z11xphl4c1nwfph0001yh/T/../0/com.apple.nsurlsessiond: stat: Operation not permitted

If you disable SIP you can poke around inside this Data Vault to learn more about how it’s structured but, as I mentioned above, this is not publicly documented and thus subject to change.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] I never managed to work out exactly which release, but if you need to know for sure you can open a DTS tech support incident and I’ll research that.

[2] Some Data Vaults have the

UF_DATAVAULT

[3] While booted from the disk containing that Data Vault.

Thanks, testing access to "/Library/Preferences/com.apple.TimeMachine.plist" seems to work a little better. I will test how robust it is on different machines.

> I know this is off topic, but how do you handle APFS copy on write?

I don't. To the best of my knowledge, Apple doesn't provide a lower-level API to deal with APFS blocks, in order to count them correctly for copy on write. And there is no sign that Apple is going/want to do it, unfortunately. On the bright side, it doesn't seem to cause a lot of problems, maybe copy on write is not all that common or often on startup disks of regular users.

Thanks! That's very interesting. I have no plans to explore Data Vaults any further. I have no interest in anything on the other side of SIP.

However, I have seen a number of reports about missing disk space. Sometimes they can be explained by local snapshots (which are about as opaque) or Spotlight, but not always. One unusual one was a 231 GB Keychains folder with 69K files. If one of these Data Vault processes loses its mind, the only way to recover would be a complete wipe and reinstall.

I have filed an enhancement request, FB6188278. If any developer comes across this thread, please "+1" this ticket number.

Pardon my ignorance, how do I find where those enhancement requests can be found, could you give me a link?

I am in the same boat with an app (Find Any File) that's finding files by name and other metadata properties.

If the user wants to see all files that were changed in the past 2 minutes, for instance, I might stumble onto FDA-protected files such as those for the Calendar and Contacts apps.

When I try to show them with FDA not granted to my app, macOS will ask the user for each of these folders whether it wants to allow my app to access them. And if later macOS versions protect more such folders, it'll get only worse. That's why I like to request FDA for my app. But to do that, I have to know whether it's already enabled, or I'd keep asking the user. Or, if the user already granted invidual access to Calendar earlier, my can't figure out whether it has FDA by trying to access the calendar (and even if, it would just bring up the prompt again, and my app won't be any wiser).

The amount of support mails I keep getting recently (since 10.13 and later) is getting quite high, just because people can't understand or figure out why my app won't find stuff they clearly see with the Finder. It not only is a pain for me to handle but also adds frustrations to the Mac users in general. But I suspect you know that already, Q. 🙂 Just wanted to voice my frustration with the current state of all of this.

Before 10.13, FAF was, for years, selling without hardly any effort. In the past 2 years, it's cost me a lot of time and nerves, and it's not looking to get any better, but rather worse. Same for my other product, iClip.

Sigh.

Is there a way to enable FDA from say, a .plist of your app? I don't want to have to enable FDA through a clickable GUI, rather a more automatable fashion for an app to gain FDA.