The Rules for Full Disk Access

Question

Created Aug ’18

Replies 37

Boosts 0

Views 29k

Participants 11

Because we are still anxiously awaiting the documentation on the workings of the whitelist in System Preferences > Security and Privacy > Full Disk Access (previously Application Data in earlier betas), I report the following experimental results with macOS 10.14 Beta 7 (18A365a): [Edit 2018-08-22: Beta 8 seems to be the same.]

If I click the + button under the whitelist and enter my .app, it gets access as expected, but only if it is located in /Applications, and not attached to by lldb (not running in Xcode).
Even if the full path to a command-line Helper tool which my app contains (/Applications/MyApp.app/Contents/Helpers/MyHelper) is explicitly entered into the Full Disk Access list (*), and it appears in the whitelist separately from my .app, this command-line tool will be denied access when it runs. (Access worked in macOS 10.14 Beta 3. Beta 4 broke it.)
After I similarly enter /Applications/Arq.app/Contents/Library/Arq Agent.app into the whitelist, overnight backups in the background by the backup app which I use, Arq, start working again.
If I have one copy of a .app already entered into the whitelist, and + add another copy, the whitelist silently remains the same, showing only one entry for the duplicated app. (Unfortunately, the whitelist does not show an item's path in any way – no tooltip.)

Therefore, I conclude that, in order for a executable to be granted Full Disk Access, it must be…

the main executable of a whitelisted .app, although it is OK for this whitelisted app to be a helper/child of another app, located in the parent app's Contents/Library.
not attached to by a debugger.
located within /Applications.

Although whitelisting a certain .app will enable its main executable and any child processes, it will not enable a helper/child app when the helper/child is launched by others in the background. The helper/child must itself be explicitly present in the whitelist.

* * *

If anyone can confirm, deny, or elaborate on these conclusions, I would really appreciate it. There is maybe only four weeks to go, and it appears that I have a lot of work to do. Was the breaking of command line tools in Beta 4 intentional?

(*) To enter a helper component such as this into the whitelist, because the navigation sheet presented by the + button will not navigate into .app packages, the user must hit the + button, then ⌘⇧G, then enter the absolute path to the helper.

P.S. to other developers: The new restrictions are apparently implemented with System Integrity Protection (SIP). You can still debug your app if you disable SIP 😟

Boost

Answer 1

Ando OP

Oct ’19

Hi eskimo,

I DID submit an enhancement request. 🙂

The reason I replied to this dormant thread is that it is the most informational post I've found on "Full Disk Access".

I'm finding that on Catalina, even when I *DO* grant my app Full Disk Access, when I call contentsOfDirectoryAtPath on many folders (such as /Applications/Utilities) the call returns an EMPTY array and a nil error. Even though there ARE of course applictations in that folder.

Further, if I copy, say, a text file into the Utilities folder, then contentsOfDirectoryAtPath returns that file in its result but still no applications!

What gives? Why can my app not "see" ALL contents of any given folder when it has been granted Full Disk Access?

0

Answer 2

Ando OP

Oct ’19

You may be right John, but what a boring world it'll be (for me)... I've always loved writing utilities that "extend" the OS features... if each app is walled off then there is no such opportunity to be "a part of the OS".... I can see the writing on the wall though... looks like my apps will have be sunsetted and my fun curtailed...

0

Answer 3

john daniel OP

Oct ’19

That is because you shouldn't consider the path /Applications to be an API. There are, by default, no files in /Applications/Utilities.

This is not a security issue (well, it is, but that's a long story). This is a side effect of how system files have been re-arranged in Catalina.

Why do you want to access that directory anyway? You shouldn't be copying text files there. I assume that was just a sanity check.

The files that you might see in the Applications folder in the Finder now reside, on disk, in multiple places. System files are in /System/Applications. 3rd party files are in /System/Volumes/Data/Applications. But, in most cases, your software has no business being in either. The few case where you might have a legitimate need to access /Applications, you can do so using the /Applications firmlink which will return the contents of /System/Volumes/Data/Applications. And don't forget about ~/Applications. These files aren't merged in the Finder, but they do show up in LaunchPad.

Does all this make sense? If so, good! That makes one person. 🙂

0

Answer 4

DTS Engineer OP

Apple

Oct ’19

I DID submit an enhancement request.

Cool. What was the bug number?

What gives?

As john daniel explained, this is because of the read-only system volume change in 10.15. WWDC 2019 Session 710 What’s New in Apple File Systems has a bunch of background on this.

Finally, if you want to find all of these directories, it’s best not to hard code the paths, but instead using

NSFileManager

. For example, this:

let userApps = try! FileManager.default.url(for: .applicationDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
print(userApps)
let localApps = try! FileManager.default.url(for: .applicationDirectory, in: .localDomainMask, appropriateFor: nil, create: false)
print(localApps)
let systemApps = try! FileManager.default.url(for: .applicationDirectory, in: .systemDomainMask, appropriateFor: nil, create: false)
print(systemApps)

prints this on 10.14.6:

file:///Users/quinn/Applications/
file:///Applications/
file:///Applications/

and this on 10.15:

file:///Users/quinn/Applications/
file:///Applications/
file:///System/Applications/

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

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

0

Answer 5

john daniel OP

Oct ’19

The forum scrambled your output.

0

Answer 6

DTS Engineer OP

Apple

Oct ’19

Indeed it did. Thanks for pointing that out.

Let’s try that again. Here’s my test code:

let userApps = try! FileManager.default.url(for: .applicationDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
print(userApps.path)
let localApps = try! FileManager.default.url(for: .applicationDirectory, in: .localDomainMask, appropriateFor: nil, create: false)
print(localApps.path)
let systemApps = try! FileManager.default.url(for: .applicationDirectory, in: .systemDomainMask, appropriateFor: nil, create: false)
print(systemApps.path)

It now prints paths, not URLs (-: And here’s 10.14.6:

/Users/quinn/Applications
/Applications
/Applications

And here’s 10.15:

/Users/quinn/Applications
/Applications
/System/Applications

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

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

0

Answer 7

webjib OP

May ’21

Big Sur 11.4 has been released, and I've got an issue with one of my apps. This app includes an Helper Tool (a bundle), that is embedded in the LoginItems subfolder. This helper tool is launched thanks to the SMLoginItemSetEnabled API.

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 by eskimo.

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

Did someone find a solution to this?

1