{"id":24194,"date":"2019-02-05T16:29:24","date_gmt":"2019-02-05T21:29:24","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=24194"},"modified":"2020-07-03T16:49:10","modified_gmt":"2020-07-03T20:49:10","slug":"mojave-privacy-protection-aftermath","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/02\/05\/mojave-privacy-protection-aftermath\/","title":{"rendered":"Mojave Privacy Protection Aftermath"},"content":{"rendered":"

Paul Kim<\/a>:<\/p>\n

\n

Months later, the issues stopped (or at least people stopped reporting them). I can’t say whether some sort of bug was fixed or if people are just now more familiar with how all the new privacy protections work. I’m leaning towards a bug of some sort as the reports have stopped altogether; I’d expect the occasional report of confusion if it was just a knowledge thing.<\/p>\n

[…]<\/p>\n

Regarding unit tests, it seems that changing my unit tests to run within an app, and adding the appropriate usage strings to the test app, was enough to get them to run.<\/p>\n

[…]<\/p>\n

At least, there seems to be one way as a dev to be able to make sense of things. Accessing protected directories (for instance, by using access()<\/code>) will fail with an EPERM<\/code> error. This differs from accessing a directory protected by UNIX permissions. In those cases, you will get an EACCESS<\/code> error. While that’s great for differentiating between the two cases what’s unclear to me is if there are other situations, outside of Mojave privacy protections, that would give me an EPERM<\/code> error.<\/p>\n<\/blockquote>\n\n

Howard Oakley<\/a>:<\/p>\n

\n

Imagine playing a team sport, and midway through a match the referee tells you that all the rules have changed, but they’re not telling you how, just that what you have been doing so far has been banned – in part.<\/p>\n

[…]<\/p>\n

For the last five months, I have looked high and low in Apple’s developer and user documentation for an official account of this, and information as to how TCC determines the Attribution Chain, which in turn informs us – developers, sysadmins and users alike – which app or tool we should add to the Full Disk Access list.<\/p>\n

You already know the answer: Apple has not even mentioned any of this. Mojave’s privacy protection is undocumented, by Apple at least.<\/p>\n<\/blockquote>\n\n

Daniel Martín<\/a>:<\/p>\n

\n

Here’s an interesting Mojave support document<\/a>. I didn’t know that you can use a configuration profile with the “SystemPolicyAllFiles” key set to automatically grant full disk access to apps. Convenient!<\/p>\n<\/blockquote>\n\n

Howard Oakley<\/a>:<\/p>\n

\n

Some of the most intractable problems in Mojave are those arising from its new privacy protection. The Privacy<\/strong> pane in Security & Privacy<\/strong> and the command tool tccutil<\/code> intentionally give users, sysadmins and developers almost no help. Most of the lists in the Privacy pane aren’t directly controlled by the user, and all tccutil<\/code> seems able to do is wipe the contents of those lists. When you have a problem, you’re stuffed.<\/p>\n

[…]<\/p>\n

I have now extended my free app Taccy, which already helps you examine entitlements and settings in an app, to provide customised access to the unified log which should make troubleshooting privacy control a great deal easier. If you’re familiar with Cirrus, which does the same for iCloud, then you’ll already be familiar with this new feature.<\/p>\n<\/blockquote>\n\n

I’ve had lots of customers try to give an app Automation access or Full Disk Access, but find that it just doesn’t work or doesn’t stick. This page<\/a> from the SpamSieve manual documents the different levels of resets that you can do to fix the problem: tccutil<\/code>, manually deleting the TCC database (requires temporarily turning off System Integrity Protection), and reinstalling macOS. These are crude remedies, but fortunately they do work.<\/p>\n\n

Previously:<\/p>\n