It's well known that if you drag a file from Finder and drop it into Terminal, the full path of the file will output in Terminal. The same behavior occurs with copy and paste too. This has always been a very convenient but innocuous operation… until macOS 10.15 Catalina. 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!
File access privacy protections were introduced in macOS 10.14 Mojave and then expanded in Catalina. Mojave restricted access to directories such as
"~/Library/Application Support/AddressBook" and
"~/Library/Safari". Catalina added even more restricted directories, such as
"~/Documents". I've discussed macOS privacy protections (and their shortcomings) several times before on this blog. You can grant special exceptions to the built-in file access policies by clicking one of the much beloved permissions dialogs that pop up in Mojave and Catalina or by manually configuring the exceptions in the Security & Privacy pane of System Preferences. That's all quite explicit to the user. What I just discovered, though, is that on Catalina you can also implicitly — even accidentally — grant special exceptions, not only to the built-in policies but also to your own explicitly chosen special exceptions. I'll illustrate with an example.
I'm going to focus on the Terminal application, located at
/Applications/Utilit… haha, just kidding, it's been moved in Catalina to
"/System/Applications/Utilities/Terminal.app". On a fresh install of Catalina, Terminal has no special permissions, as you can see in System Preferences:
When I try to list the contents of the Documents folder in Terminal, I get a permissions dialog, because Millennials are killing Unix.
When I press "Don't Allow", then I see "ls: Documents: Operation not permitted" in Terminal. My decision is also displayed in System Preferences; the Documents Folder is unchecked under Terminal.
Now I copy the Documents folder in Finder and paste it in Terminal:
Suddenly it works! Why? 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!
com.apple.macl extended attribute is so persistent that you can't even delete it. Seriously.
It turns out that the
com.apple.macl extended attribute is governed by System Integrity Protection, so the only way to delete it is to disable SIP, or boot into another volume and delete it from there. Thus, once you implicitly grant special access to a file, you can't easily revoke that special access.
As far as I can tell, there's no documentation of this important privacy protections change in Catalina. The only reference to
com.apple.macl that I found on Apple's web site was in a reply to a post in the Developer Forums from longtime Apple Developer Technical Support engineer "Quinn". That reply was suggestive but sparse with details. The post wasn't even about Finder and Terminal but rather about the open panel in non-sandboxed apps.
I just discovered all of this last night, so I'm still not fully clear about the implementation and implications of the
com.apple.macl feature. I welcome further investigations by other people. Besides the lack of documentation, there seem to be several problematic aspects, such as the inability to delete the extended attributes, and the fact that the implicit access can directly contradict the explicit access shown in System Preferences. Keep in mind that I only used
"~/Documents" as an example, and implicit special access can be granted to any file or folder. This can even lead to the bizarre situation in which Terminal has access to a file but does not have access to the folder containing the file, a situation that was the "inspiration" for my discovery.