It’s hard to believe that Mac OS X originally survived with just conventional Unix permissions and privileges. Since those happy days, we’ve gained SIP to ensure that even root can’t access much on our Macs, then in 2012 we gained TCC to turn privacy control into an ongoing battle for many. This article looks at what you can do when TCC is playing up, as seems to afflict many users. Should you try to fix it using the tools provided, or give up, trash its database, and start afresh?
When TCC was described at WWDC 2018, its initials were explained as meaning Transparency, Consent and Control. Since then it has been so transparent that Apple has provided minimal documentation, either for users or developers. Current support documents include detailed listings of each of the protected categories in the context of their controls in System Settings, and additional information about ‘advanced settings’. Even the Platform Security Guide contains scant information, and nothing to aid those dealing with problems. The one maintenance and repair utility, the command tool tccutil , has a brief and unhelpful man page that hasn’t been updated since initial release in 2012.
These have grown from the simple settings for seven categories in macOS Sierra (above) to 20 categories in Ventura’s Privacy & Security (below). Some, like Full Disk Access and Files and Folders, overlap, while others like Accessibility have simply been misnamed. Controls provided vary between different categories, and many users dread having to tinker with them.
Depending on which category you look at, the user may be able to add and remove apps, as well as enabling and disabling an app’s access to protected data or services. macOS then translates those settings into its database for use by TCC when determining whether a process can access a service or location on disk. Control of access to Files and Folders is particularly intricate, with both global Full Disk Access and per-item controls for specific folders and removable volumes.
In theory, at least, apps should contain informative text to explain to the user when they request access to controlled services and locations. But some apps appear to be awarded access that they never requested, and once granted it just remains until the user does something about it. For example, my app Sparsity doesn’t ask for access to Reminders, has no need to, but somehow has been granted that in Privacy & Security.
One catch that has resulted in apps being given access when the user didn’t want it is the tendency of the TCC database to remember old approvals. Let’s say that you install an app Nasty, give it Full Disk Access, then decide that it’s as nasty as its name and remove it. At some time in the future, you unintentionally re-install Nasty, and it may then assume Full Disk Access without your being aware, because TCC has remembered its previous setting. Before I remove any app whose privacy is suspect, I now disable its access beforehand, in Privacy & Security, then leave those settings in place. Should it return, then its access should already be blocked unless I explicitly enable it.
Terminal is another concern, as its access settings determine those of the tools that it runs. While we want most of our commands to enjoy Full Disk Access, there are times when that might not be appropriate, but will be given automatically through what TCC terms the attribution chain.
When privacy settings are playing up, and you get prompted to allow access that you have already agreed to, or access fails when it should have worked, there’s little you can do about it. Once you’ve fiddled with Privacy & Security settings without success, the only tool to try is tccutil .
If problems are confined to just one or two privacy categories, then you can reset just those using a command like
sudo tccutil reset ListName
only Apple doesn’t document the ListName to be used for each category. Experience suggests you could usefully try the following:
If only one or two apps are involved, then you can reset their settings with
sudo tccutil reset All com.vendor.appname
for the app with the identity com.vendor.appname.
Beyond that, a full reset seems to be the only option.
You can completely reset the TCC database using the command
sudo tccutil reset All
What happens next is illuminating. TCC first checks that the command has the required entitlement com.apple.private.tcc.manager.access.delete , then it sets about resetting each category individually. Once those have been completed, TCC turns to iCloud, where it tries to propagate the reset, even when the user account has no Apple ID or iCloud access.
The snag with a full reset is that it relies on the TCC databases to delete current settings. If there’s a problem with either of those databases, then it doesn’t appear able to fix that.
The nuclear option is to delete TCC’s database, a process requiring the use of Terminal in Recovery mode. This has been described in detail by Robin Kunde, and fleshed out further by Glenn Fleishman at MacWorld.
The first problem with this is that it only deletes the master database, at /Library/Application Support/com.apple.TCC/TCC.db, and not its user equivalent at ~/Library/Application Support/com.apple.TCC/TCC.db. If the error is in the latter, or has replicated to it, then this might not solve the problem.
Glenn Fleishman has also extended the original procedure to include a folder containing data for ad hoc signatures alongside that database, in AdhocSignatureCache. Additional ad hoc signatures are stored in ~/Library/Application Support/com.apple.TCC/AdhocSignatureCache which are left intact. While removing those signatures shouldn’t cause irreversible change, the rationale for doing so seems to be to enable deletion of the entire folder at /Library/Application Support/com.apple.TCC rather than just the database.
This all begs the question as to how the TCC database became corrupted in the first place. After all, it’s better to treat a cause rather than a symptom. As many users seem able to go for years without suffering problems so intractable as to require this nuclear option, and TCC databases are generally small in comparison with other vital system databases, it’s not easy to see how they can repeatedly become corrupted. Before removing the database, I think it would be preferable to discover what’s happening in the log. com.apple.TCC isn’t shy when it comes to detailing what it’s doing in explicit log entries. Those might reveal a cause that’s more amenable to treatment.
