This indeed seems dangerously counterintuitive.
I, like most other people I'd think, always assumed the permission dialogs ("TCC") were a layer of restrictions on top of traditional UNIX user permissions. Not overriding them.
In other words, granting full-disk access to an app would give it access to everything my user can access. Not "sudo" access to other users' data as well.
Why would an app ever need that level of access? For installing files, maybe, but not while running.
Can anyone else confirm this is how macOS actually works? And if there's some justification I'm missing? It seems so crazy that I can't actually believe it without somebody else verifying it.
An admin has always been able to sudo to bypass normal Unix permission checks. That's true on all Unix systems.
All of this smacks of different parts of the macOS core team not understanding their security model. One half seems to think Full Disk Access just means "has the user's file system permissions instead of sandboxed access" (hence why Finder has it), while the other thinks it means "access the whole disk, regardless of other permissions". Both interpretations are reasonable but become unreasonable when combined into a single system.
Can an app given full-disk permissions not access data in other user folders other than the user who started it?
This is why I'm so confused.
> Why would an app ever need that level of access? For installing files, maybe, but not while running.
Though bootable full disk backups aren’t possible anymore with the recent releases of macOS, there are applications such as Carbon Copy Cloner and SuperDuper! that need full disk access to create a backup of the entire volume. This is a limited case, but there are many people who use these (instead of or in addition to Time Machine).
It is explicitly detailed as such. Full disk access actually means full disk access under that system.
> Time Machine backups [...] for all users on this Mac
A less ambiguous warning is needed if this is truly meant to be such a powerful setting that overrides regular user-based permissions.
> Bypassing macOS TCC User Privacy Protections By Accident and Design
Simply because 'backdoor' is especially vague - I first thought it was about Apple backdooring their users perhaps, but it's a way for malware to abuse Finder to bypass the 'Full Disk Access' permission prompt. It's also not an editorialized title.
Submitters: "Please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html
On a computer shared by multiple people and multiple applications, shouldn’t privileges be assigned at the intersection between user and app (and or groupings thereof)? And if there was some sort of privileges table, it would have a composite key consisting of app-id and user-id.
Is any modern OS actually set up that way and if yes, is there any way to generate a report to show the combination of user/app privileges?
Many server applications handle user separation internally, without reference to the underlying OS, while application separation is much stronger (separate VMs, SELinux, etc.), and desktop platforms have user separation but often-unsandboxed apps, so those are in some ways duals of each other…
I'm not sure what Windows does with UWP and sandboxed apps from the Microsoft Store, but that would be a good place to look.
Except now we have two permission problems...
How does this interact with regular Unix file permissions? Is the assumption that Alice is using sudo, or do modern macOS versions mark all user files world-readable?
By default, a user can't see another user's files.
I feel Apple tries to hide complexity from the user too much. I understand they want to do this by default but there should be a way for technical users to know what's going on. I don't think that's the case well enough now.
Especially that thing with the full disk access cascading though the automation permission is very vague.
This is completely separate from the unix user permissions.
It's supposed to be separate, but, with the Time Machine hole, it actually overrides them. So, if an admin enables FDA for Terminal (so that they can actually use it), then a Guest account on the system can use Terminal to create a TM snapshot, mount it, and read any file on the system, from any user, regardless of Unix file permissions.
(1) Create a snapshot of the entire file system; (2) or find a recent Time Machine local snapshot; then (3) mount the snapshot obtained in [1] or [2] without owners enabled, effectively granting Alice read-only access to other people's files without having administrative privileges.
Basically, it acts as a sandbox rule. Sandboxing your app doesn’t allow you access to new files, it just denies access as determined by the sandbox profile.
