Last Week on My Mac: Catalina users caught in a game of chance

When it comes to basics, we like consistency. Imagine what life would be like if every so often gravity changed direction so things fell sideways, or varied its intensity at random times? That’s the same unnerving experience which Catalina introduces when it comes to accessing files.

Over the last few weeks, I’ve reported several such cases. First, there’s the curious case of AppleScript and resource forks, where accessing resource forks can suddenly become blocked. Then I found a case where Apple’s own Preview app couldn’t overwrite a PDF file, but readily did so with images. Most recently there’s the bizarre glitch in two of my apps, which can’t save logarchives to external drives, even though they can write them to the startup volume.

Common to these and similar problems which users are reporting are three signs:

  • they involve actions on locations included in privacy protection introduced in macOS 10.15,
  • the error is marked by a single log entry from the kernel involving sandboxing, although the processes involved aren’t sandboxed,
  • the new extended attribute com.apple.macl is attached to the file or bundle involved,

and the issue is new to Catalina.

Catalina’s new per-file privacy protection is so complex that Apple has, as yet, been unable to explain it to either users or developers. What was shown at WWDC last June was clearly just the tip of an iceberg, one on which quite a few processes are starting to founder. Instead of the user’s intent determining what happens, as Apple claims, or the user’s patience being tested with another barrage of consent dialogs, macOS is now applying rules which are so byzantine in their complexity that they appear arbitrary.

logarchdemo1

In the case of saving logarchives, the situation appears nonsensical. Run from Terminal’s command line, log collect can save pretty well anywhere you like, provided that permissions are in your favour. When called within an AppleScript script, the same tool can’t write to an external, non-boot volume, even when both Script Editor and the log command have been added to the Full Disk Access list of the Privacy tab of Security & Privacy. In Catalina, Full Disk Access therefore no longer works as advertised, as hidden rules can and will override the user’s intent.

logarchdemo2

The script here is simply based on
do shell script "log collect --output '/path/Test1.logarchive' --last 1m" with administrator privileges
where /path/ is the full path to a location in the ~/Documents folder, or one on an external volume.

It’s this which is most frustrating of all, that neither the user nor developer gets to know, let alone grok, the rules, nor do they appear able to modify them so that macOS works the way that they expect it to. Controls in the Privacy tab don’t appear to apply to per-file privacy protection accomplished using the com.apple.macl extended attribute, and as the extended attribute itself is protected by SIP, neither user nor developer can remove or modify it. There’s no override feature, no off switch, and no way to get your Catalina Mac to forget about per-document privacy protection and its bizarre behaviours. When you’re trapped with a document that’s behaving like a crazed cat, there’s just nowhere to go.

We’re only three months into Catalina’s year, and at present these problems appear sporadic, as the dreaded com.apple.macl extended attribute is still relatively uncommon. With more users migrating, and early adopters completing more work using Catalina, what’s currently occasional can only become more common. That’s unlike barrages of consent dialogs, which occur mostly when first trying to give apps access to protected resources.

When we don’t know what behaviour is intended to be normal, it’s also impossible to even guess whether these might be bugs. Investigation is difficut, involving careful checking of permissions, elimination of command errors, and more. The single diagnostic entry to the log is easily overlooked, tests using different privacy settings can be protracted, in this case I resorted to building different versions of the app in an attempt to find a workaround. In the end, confirmation came only after I had found the distinctive extended attribute and ruled everything else out.

If this is how per-document and folder privacy is going to work, then it turns using files in macOS into a game of chance, and it’s a chance that is only going to deter users. When privacy protection has these unpredictable and obstructive effects, it’s surely time to consider whether it isn’t bringing the whole of macOS, and by association Macs, into disrepute.