Comment by Angostura
12 hours ago
I think I’m probably being dumb, but the gotcha here seems to be - ‘if I give an application permission to access a folder, it has access to the files in that folder’ - which is what I would expect??
12 hours ago
I think I’m probably being dumb, but the gotcha here seems to be - ‘if I give an application permission to access a folder, it has access to the files in that folder’ - which is what I would expect??
Yes, you need to read more carefully. In particular:
“8. Confirm that Documents access for Insent is still disabled in Files & Folders.
“9. Whatever you do now, the app retains full access to Documents, no matter what is shown or set in Files & Folders.”
[…]
“Access restrictions shown in Privacy & Security settings, specifically those to protected locations in Files & Folders, aren’t an accurate or trustworthy reflection of those that are actually applied. It’s possible for an app to have unrestricted access to one or more protected folders while its listing in Files & Folders shows it being blocked from access, or for it to have no entry at all in that list.”
"6. Click on Open from folder and select your Documents folder there. Confirm that works as expected and displays the name and contents of one of the text files in Documents."
It's because in step 6 the user explicitly selected the Documents folder.
The app can access the Documents folder because the user chose that directory in the native file browse dialog during the same run of the app. IMO that's a reasonable trade-off.
The problem is that this given permission doesn’t show in Files & Folders, and after turning it on and off there it still persists. The only way to revoke it is using some CLI command and restart the computer.
31 replies →
> during the same run of the app
Is this part true? The article's fix involves running a command and rebooting the computer. If restarting the app was sufficient, surely you wouldn't need the command/reboot?
1 reply →
Screen time is swiss cheese as well, not surprised.
This is so typical for Apple software "quality". While a truly love some of the features Apple has put into my pocket, I am noticing since years that at least iOS is the first commercially sold platform where I sometimes have to press a boolean toggle twice to have it take effect. They seem to have a lot of bugs around UI synchronisation.
The gotcha is “I gave it permission, then revoked permission in the UI, but it still has permission.”
That's not quite it either. It's more along the lines of "I revoked access via one mechanism, then granted it via a different mechanism, and the setting UI for the first mechanism doesn't reflect the second action".
There's no privilege escalation here, but there is a misleading privacy settings UI, which offers no obvious way to audit/revoke permissions in the second case
I think the issue is more like:
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism.
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission survives the action context that triggered the file picker (e.g "pick a folder to do action A" also magically imbues similarly gated actions B C D and Z with access to that folder, possibly non-interactively even).
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission propagates to an action gated by the first mechanism, a first mechanism for which "Yes" means yes but "No" means "Maybe, depending on past unrelated actions that triggered an unrelated permission mechanism"
1 reply →
Not quite. The steps are revoking permission in the UI (which works as expected), then implicitly granting permission in a way that the UI does not reflect but quietly persists.
So basically the opposite of Windows NTFS and SMB access. Windows is tricky but this is just bad.
TFA intro (emphasis mine):
> In this Friday’s magic demonstration, I’m going to show how what you see in Privacy & Security settings can be misleading, when it tells you that an app doesn’t have access to a protected folder, but it really does.
One might expect macOS to recognize “you selected a folder that’s already got a UI associated with it” and to wire this up on the backend through the UI rather than creating a simple path exception that leaves the UI nonfunctional. I would have just filed a feedback report about it; but, the outrage-framing of that is, in historical context for this particular site, normal. They have posted extensively about Gatekeeper and TCC issues and seem to encounter them rather more reliably than others do, and released various tools (including today’s!) to support debugging, so certainly I empathize!
It’s really poorly written. After reading it all I still can’t figure out what’s the mechanism by which revoked permissions are hanging around, which is what would actually be interesting here.
It is poorly written. I have suspicion that the author is talking about the persistent file permission mechanism known as Security-Scoped Bookmarks, but the article makes it hard to understand what exactly is being discussed. It reads like a raw bug report without any analysis done.
And specifically they could show some code snippet to reveal what exactly the Insent app was doing. Was it calling startAccessingSecurityScopedResource of the NSURL class?
My impression is that the revoked permissions do not persist. Rather, an interactive window running under the user’s name has implied access to the user’s home folders, regardless of what’s been set under “Files & Folders” (which still applies for background/non-interactive processes).
I could absolutely be missing something here, but the title would be accurate in saying, “MacOS ACLs aren’t terribly intuitive”. But I think the behavior they’re documenting is intended behavior.
I’m glad I don’t even rely on this dumb system in the first place. I just run programs that don’t do shady shit. Wish I could disable these idiotic prompts entirely and go back to how it was before.
“Word” would like to access the files in your “Documents” folder
“Terminal” would like to access the files in your “Downloads” folder.
Yes, because I am telling them to access the files.
>I just run programs that don’t do shady shit.
you hand-audit every update for every program you run? can you share your workflow to do this?
otherwise, i am not sure how you can possibly guarantee that the programs you are running "dont do shady shit" (or, "wont do shady shit" in the future). there have been several compromises of non-shady programs and libraries in recent memory.
Wow... that would be great.
All that remains is an algorithm to reliably determine which programs do "shady shit". How is it that you determine that Microsoft updates have not been tampered?
(insincere) apologies for the snarky tone. You are making light of a very hard problem and default deny until confirmed by the user isn't a bad first approximation.