Full Disk access permission showed not correctly on some macOS

We use MDM profile to apply Full Disk Access permission for app on macOS. After profile deployed successfully, the App can get correct Full Disk Access permission. However, on "Privacy & Security" UI, we found that our app shown disabled, see as

So, just to make sure I understand the issue:

1. In all cases, the app itself is successfully granted FDA, allowing it to read whatever it needs to, etc.

2. In some set of unknown circumstances, the "Privacy & Security" UI does NOT show the app as having FDA, despite the fact that it does in fact have FDA.

Assuming that's correct, the basic answer is that #2 typically caused by some issue with details of either the machine’s configuration and/or the specific config profile. Determining EXACTLY what configuration is involved isn't straightforward, but that's the basic answer about what's going on. Two specific cases to be aware of:

(A) The full range of configuration options mean that it’s possible to create a machine configuration that's inherently contradictory. Case in point, while a profile can grant FDA to a specific application, I believe it's also possible for the same profile to say that FDA can't be granted to ANY application. This isn't even accidental, since there are cases where you want to grant specific apps/components FDA but also prevent any OTHER app from gaining FDA. This can also happen across multiple profiles, so the configuration can happen even if your profile DIDN'T include particular setting.

However, what to display in this scenario isn't obvious. We have to disable the UI (since the user can't change it), but having an "enabled" setting you can't change is also disruptive. There's also a minor performance issue— the global setting would let you skip individual app checks, but showing the "right" setting means assessing every app, even though we ("probably") know that most/all of them "should" just be set to "no".

I can't promise this is what's happening in your particular case, but this would be my first guess.

In any case, that "probably" then leads to the second issue...

(B) The way MDM overrides are actually implemented tends to be driven by our own implementation simplicity, not what presents the most accurate UI or appears "correct" to all tools at all levels of the system. For example, many of the TCC overrides basically work as fixed "overrides" at the bottleneck that implements the very specific privacy check. This causes the least disruption to the broader system and also helps provide a smoother behavior "flow" as profiles come and go. For example, if you try the following for most of our checks:

• Approve the app for a specific permission.

• Install a profile that denies that app the permission.

• Remove the profile.

...You'll find that the app is still authorized after the profile is removed, even though it didn't work while the profile was installed. That happens because the profile block never actually interacted with the TCC database, so the original setting stayed "as is". This approach is also the most secure option, as putting the MDM override as "low" as possible minimizes the opportunity to bypass the check by using some alternate, lower-level API.

HOWEVER, it does have one major downside in that it can make it hard to keep higher-level interface "synced" up with reality. Case in point, in the example above, direct inspection of the TCC database will show that the app is "authorized" even when the profile means it's NOT going to actually.

With all that context, returning to the issue here:

1. In some set of unknown circumstances, the "Privacy & Security" UI does NOT show the app as having FDA, despite the fact that it does in fact have FDA.

It's certainly worth filing a bug on this, particularly if you're able to identify the specific circumstances that create the issue. However, I think it's also important to understand that the realities of the system mean that some of these cosmetic issues may simply never be addressed, as the work required to make sure the interface is in fact "right" can often be FAR more complicated and involved than the MDM check itself. In many cases, it just makes more sense to accept the UI issues and stick with the simpler implementation.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for your reply.
About Full Disk Access permission, when deployed via MDM, TCC db query seems also not correct in some machines.

sudo sqlite3 "/Library/Application Support/com.apple.TCC/TCC.db" \ "SELECT service, client, auth_value, auth_reason FROM access WHERE client LIKE 'bundleid%';"

Do we have other method that can correctly check Full Disk Access permission granted by MDM profile?

Thanks