Wednesday, December 18, 2019

Persistent File Access via com.apple.macl Xattr

Jeff Johnson (Hacker News):

I’ve discovered that on Catalina, pasting a file from Finder not only outputs the file path in Terminal, it also invisibly and permanently grants Terminal access to the file, bypassing any macOS privacy protections!

[…]

Notice that after copying from Finder, the Documents folder has a new com.apple.macl extended attribute. (I’ll assume the “l” in “macl” stands for “lockdown” until someone tells me otherwise.) This special extended attribute gives Terminal (and possibly other apps?) special access to the file. The com.apple.macl extended attribute, as well as the special file access, is persistent across reboots. Indeed, it remains even if you reset the privacy permissions of Terminal!

The com.apple.macl extended attribute is so persistent that you can’t even delete it.

Unless you turn off System Integrity Protection. This seems so much more convenient than the way it works for sandboxed apps, where the app is responsible for storing and using a security-scoped bookmark.

See also: Quinn the Eskimo.

Update (2019-12-19): Rosyna Keller:

Indeed, this was documented in the Advances in macOS Security session at WWDC. To prevent spurious dialogs when a file access is clearly due to a user action (like dragon drop/manual file opens, double-click in the finder) access is inferred by the user’s action and granted.

I watched that session and don’t think it really conveyed what is going on:

And user privacy protections in macOS Catalina now support the notion of user intent, when-- which is inferred when double clicking on files in Finder, when dragging and dropping from another application or when selecting files in an Open or Save panel.

And when the user performs any of these actions, the file-- performing any of these actions on a file protected location, your app gets access to the file or files that the user selected without the need for a consent prompt. So let’s see how Catalina’s inference of user intent compares with user consent. Sorry. So, first of all, user consent is reactive. Access may be granted only after your app tries to read or write a file, whereas user intent is proactive. Access is granted before the app, even tries to read or write the file. And user consent prompts to kind of interrupt the user’s workflow, whereas user intent is inferred from standard UI interactions. In order to minimize those interruptions, user consent applies to an entire class of data, for example, all files on your desktop.

Whereas user intent is inferred for just the file or files that the user is interacting with.

Jeff Johnson:

As developers, we need to test our software under known conditions. That’s when all these inscrutable irrevocable privacy protection exceptions become a nightmare. tccutil reset was good enough on Mojave, but now it’s not on Catalina. Apple offers no good solution to the problem.

Update (2019-12-20): Howard Oakley:

The com.apple.macl xattr contains a list of UUIDs for the apps which can open it, each with a prefix 0100 containing a single flag which presumably grants that file-specific entitlement. There can be one or several UUIDs, which are stored there in binary, not text[…]

[…]

There are some worrying features in Catalina, though. I have written before about the promiscuous use of the quarantine flag on documents in Mojave and earlier. I regret to report that this behaviour doesn’t appear to have changed at all, and in many current Catalina installations the new com.apple.macl xattr will be outnumbered by all those devalued quarantine flags. This also gives rise to some strange consequences: open a PDF in Preview without saving it, and it will be given a quarantine flag but no com.apple.macl xattr. If you try to Save that to overwrite the original document, Preview promptly refuses, and may not even be able to write that file out under another name. Repeat that with a PNG file, and Preview has no such problems.

Previously:

Jeff Johnson:

At least with the quarantine xattr, the value contains the bundle id of the app that wrote it. The macl is effectively untraceable.

Update (2019-12-26): Jeff Johnson:

I received a link to a video from the PSU Mac Admins conference in August that mentioned the macl xattr I blogged about recently.

Not much new info on that subject, but relatedly, the speaker said the quarantine xattr may apply to curl in the future!

5 Comments RSS · Twitter

How to delete this attribute from a file?

[…] these are good questions, but there’s no official documentation. A good start is this assemblage of articles, here’s the highlights from that page and a few […]

I encountered the same problem where Preview disallowed saving edits to a PDF because of this flag, and can confirm that the below workaround allows you to do so when you encounter this issue.

https://discussions.apple.com/thread/250850461

Hmmm - I seem to have run into this problem. I'm uploading files from an external drive to an account on Zenfolio that I use for my photos. The drive contains my photos. A batch of files resulted in a series of files not able to be copied. Looking around for the cause, it seems like the ones that can't be uploaded have the @ on an ls -l command. I did a search to see how to delete the extended attributes, and it looks like it doesn't work using the techniques suggested. I can open the files in preview. I just can't upload them to my zenfolio account. Here is a sample output from ls -l@

-rwxrwxrwx@ 1 victorengel staff 1995282 Dec 31 2010 IMG_9008.JPG
com.apple.macl 72

What can I do to make these files able to be uploaded?

Never mind. This may be unrelated. I tried uploading other files and they don't work either. Seems like a server-side issue. It's still a mystery to me where those extended attributes came from. My workflow typically is using Lightroom in Mojave to copy files to local drive, then rsync to copy them to the remote drive. Another workflow uses Lightroom to export the files. Anyway, I see no difference in workflow between ones with the extended attributes and ones without. Most of my dealings with the files are in Mojave. However, I back them up to Idrive using Catalina. Why? Because my version of Lightroom is incompatible with Catalina. But I'll eventually be migrating to Catalina. I have to use Catalina to access some of the APIs for my iOS development. For example coding in SwiftUI is not possible on Mojave.

Leave a Comment