Posted by zdw 6 hours ago
The app somehow gained a permanent permission that I didn't give and that I can't remove no matter what I do. That's not working properly in any sense.
This is not true, you do give consent when you pick a folder to open
In the case of sandboxed apps, this is not true. The open panel provides temporary access, and a sandboxed app needs to create a security-scoped bookmark to retain persistent access across launches.
For non-sandboxed apps, it's usually not an issue, because non-sandboxed apps have access to most of the file system by default. The weirdness occurs only for certain files and folders that are restricted by TCC, such as Desktop and Documents. But for non-restricted folders, nothing needs to be done. Observe that if you use the Open from folder... command from Insent on a non-restricted folder, then no com.apple.macl is set on the folder. No special permanent access is granted, because none is required. The only time the system automatically grants permanent access is with TCC-restricted files and folders, so we can't pretend that this is a "normal" thing.
In general, non-sandboxed apps don't even need the open panel for file access. They can just read whatever file they want... except for the TCC-restricted files. The purpose of the open panel in a non-sandboxed app is just to provide a file picker UI to the user.
And this is for sandboxed apps. You correctly point out that non-sandboxed apps have even more access. So a user’s mental model should be that all open dialogs grant permanent access.
It seems most likely that this is some kind of bug where that command or its underlying actions should be called every time the user unchecks something in the settings panel.
This is what we get when the iPhone’s permission system is grafted on top of a desktop OS that was never designed for it. I think they could have done something that is more Unix-like and yet friendly to the GUI end user.
And it absolutely was a magic fix. I stand by it.
(You could see permissions errors in the logs that would go away after running it, which often didn't really fix anything but could make it faster since it didn't have to error out.)
Giving access to a file via the Open and Save panel is an explicit declaration of consent.
Because the panel is provided by OS itself, the app doesn't get access to the item until the user has selected a folder or file through that panel.
The UI just doesn’t reflect this.
That's the bug. Either that or MacOS has two separate/distinct mechanisms for managing permissions, which would be a huge security flaw.
VPN should be properly implemented though as you're able to verify network requests on your own and don't necessarily have to trust apple. Best guarantee is to have a VPN at router level that can't be circumvented by anything (+ a trusted router vendor)
[1] https://www.macworld.com/article/675671/apples-own-programs-...
It's not a good look for Apple, and it's not great that the permission revocation basically doesn't actually work, but any malware that could have infected the system due to this issue would have also been able to infect the system while the permission was still (intentionally) enabled.
There are many apps that themselves are not malicious but they run untrusted code via plugins and stuff. Like VS Code for example.
So you gave it a permission and then revoked it thinking all is fine. tomorrow an extension was hijacked and it now reads your files. cool?
But since they don't consider these as vulnerabilities in the first place, then yeah, sure.