Updates to Full Disk Access in macOS(developer.apple.com) |
Updates to Full Disk Access in macOS(developer.apple.com) |
For communication apps, this can also compromise the privacy of the people users are communicating with.
For the "greater good" as usual.
Just look how deceptive is the Apple post "full disk access" is not even a thing. You have access to your user files and that is all. You need sudo to have more rights.
A normal copilot/Claude/facebook like app shouldn't ask you for such a right except exceptionally for a very good reason.
So when they speak about backup apps, that are the one that could need sudo to backup the whole system, is to tell you that soon only notarized apple approved and app store delivered apps will be allowed to do that, but certainly not you willingly. Maybe not in version 1 but in version 2 for sure.
Then, like for iOS, they could have proprietary apps like Netflix, Facebook and co storing data on your device that you will not have access to.
Huh? Seems like a disingenuous statement. I hope they update that sentence with something more accurate.
However, I've wanted much more granularity and pervasive permissions so I'm glad they're adding them.
Right, the classic use case for FDA is Terminal app, not backups. I don't think backup apps even need FDA, because they use the Apple ASR tool that already has special permissions.
The permissions/security model should've expanded faster. There's huge benefits to being able to install arbitrary software and not worry about giving it access to everything.
But it would never cover everything to do with a computer.
If asr can be used to bypass FDA then that is just a security vulnerability.
I had 3 duplicate files on each drive and it was impatient and rushing and didn't keep one drive around before formatting them all.
Completely saved me the week of migrating files project I was dreading, thanks. Nothing invaluable but an insane amount of downloading to do and I'm on 5g in the woods.
Sometimes its just draw dropping at how stupid these can be, basically giving a 6yo RHCSE root access.
Thus, I'm not sure what more Apple can do here, but I'm definitely afraid of what they're going to do.
In reality, the "full disk access" restriction system never actually worked right. I'm positive Apple is just trying to save face here and quietly fix it while saying they're "tighting" it
Who decided that hidden folders are a good thing anyways? .agent, .agents, .aws, .bun, .cache, .cargo, .claude, .codex , .config, .docker, .gemini, etc. I just end up having to show hidden folders all the time, which defeats the point.
It's gotten truly ridiculous. I want the OS to strictly enforce my root directory. There should be a few global preference files in there for like .zsh, and everything else organized in proper, unhidden folders.
The grey beards who designed the OS decades ago? Though the lore is the hidden fact of ".dot" was just a bug
> There should be a few global preference files in there for like .zsh,
Why, though, this can more cleanly live in your "config/shell" folder
People want a computer that prevents catastrophic mistakes and Apple has the ability to deliver that.
That wasn't the the point, though. The point is that asr has special private Apple entitlements, allowing it to do things that other processes can't, but it requires root to run asr, so asr can't be triggered willy-nilly by any user process.
> Full Disk Access largely sidesteps these controls
That's because you don't really. Just like you don't give users "powerfulf" controls, so instead they have to resort to dumb ones like "Full disk"
For example, if you care about "mail, messages, and even browsing history", why isn't there a subset of "full disk access except for reading mail/messages/browsing history"? Or if vibe code have some basic disk sizing functionality to ask questions about your files, why can't it have a more granular "full disk read only access for file sizes only" so that your vibe coded disk visualization app can't destroy your data or your privacy
> can only do so with very explicit user action.
Which is in the same vein and is mostly useless, just another inconvenient bump
I don't need file contents, I can skip showing file sizes and date modified on protected paths. Hell I can skip indexing Mail and Messages files altogether since they're pretty useless anyway. But how am I supposed to know beforehand which path will trigger a scary Cling wants to see your <private folder> when doing a simple traversal.
Similarly, window switchers like my rcmd app (https://lowtechguys.com/rcmd) need access to window titles to function properly, but for that, the app has to ask for Screen Recording permissions. I don't need to record anything, I just need the damn title text and users will be happy to give access to that, but not to recording the screen.
This goes on and on.
Want to register a more interesting hotkey like fn-letter? You have to act like a keylogger and ask for Input Monitoring.
Want to focus a specific window instead of activating the app and letting the OS decide which window comes forward? You need Accessibility permissions and full access to control the whole computer.
Want to paste some text into a text field? Accessibility Permissions.
Too granular permissions is hell. But there are these decade-old common use cases for macOS utilities that would make it much easier to keep permissions locked if they became their own permissions.
I burned a support request on this years ago, and was told that it seemed like a good idea for a future update… a API to open a Finder window at a known path.
macOS used to be one of the most power tool friendly operating systems. Apple Events and AppleScript dictionaries made automation like this so easy. Now everything requires a special permission or specialized Kit to do things that were simple two decades ago.
Window titles can and often do contain very personal information. A window titled "Planned Parenthood | Official Site" in the hands of a bad actor or some relative-monitoring spyware could have disastrous consequences.
> Want to paste some text into a text field? Accessibility Permissions.
Only if you aren't relying on user-initiated pasting like right click ' cmd+v.
It's not like people have tried to improve core security models, but in my opinion it's not really compatible with the core filesystem abstraction that programmers and power users of desktop computers demand. I think you need to move to a completely different model—like iOS for example—to meaningfully improve security controls without nerfing the OS.
How is moving to iOS's model not nerfing the OS?
I don't know if Apple has something like that. Surely they must do; Windows FACLs have been available since NT was part of the name, Linux has had them since Linux 2.5, and Apple invented a whole new filesystem relatively recently. They've also compartmentalised iOS apps since they were first released.
I'd be surprised if the currently available APIs aren't usable for applying effective restrictions just yet. Rather, I think Apple's choice is part of a process to move desktop applications towards the iOS model instead.
I don't think there's anything wrong with people not knowing how to use a computer properly. In fact, I wouldn't expect a normal person to, why should they? So what I would love to see is normies be given iPads, and my computer left the hell alone.
It's like if we over-simplified all the controls in a cockpit because someone who likes playing flying games finds it too difficult to fly a real plane.
There is no reason this couldn't work for permissions as well; beginners get the system locked down pretty well, whereas advanced users get a more open system they can do more with, at the expense of potential foot-guns)
(As a side note, we could probably make a plane that had this principle applied as well. With autopilot where it is today, we could easily make a commercial plane that grandma could fly under most circumstances - you just need that real pilot and extra controls for when things go wrong.)
https://support.apple.com/en-mide/guide/security/sec7d92dc49...
- Ghostty (fine, it's my terminal)
- Alfred (fine, I use it for searching everywhere)
Then I have a few turned off:
- Spotify (why does it need full disk access) ??
- Gemini (nope, don't need it to know everything about my computer)
For those who haven’t heard of this, sandboxed apps can request access to a file or folder and persist such access using a security-scoped bookmark. The user however does not know whether the app chooses to persist this bookmark or not; in other words the user does not know whether in each case they are granting a one-time access or persistent access.
There are already folder-specific permissions for every app, including non-sandboxed apps: Desktop, Documents, Downloads. FDA is "everything else". The user has to specifically grant each of those permissions via a system dialog.
With sandboxed apps, you grant access to a file outside the sandbox via a system dialog, open or save. But with non-sandboxed apps, if there were separate permissions for each specific folder, there would have to be separate permission dialogs for each of those folders, and then macOS would become even more of a permissions dialog hell than it already is.
Reminds me of iOS's terrible treatment of PWA local storage. A PWA's offline availability can be revoke at any time the OS decides it knows better than you what your storage should be used for.
Edit yes, you'd want proper sandboxes for software. Yet Apple's approach is "pay us 100 dollars a year for software signing and sandboxing" which is not what we want
I get that it's the safe way to do things, but even as a power user who is concerned with that type of stuff, it's overwhelming!
One niche issue resulting from this : it broke the ability to access my own screensaver settings and files from it's settings app, because those settings live inside a container for a system extension that belongs to Apple (because Apple still hasn't publicly released it's "modern" screensaver api, it's still old style plugins run by a legacy extension).
Several screensaver developers I know got bitten by this and there's no proper workaround, you just have to use "/Users/Shared" and hope that doesn't go away any time soon.
In my case it silently broke migration for Aerial from 3.X to 4.X in Golden Gate (where I moved away from the legacyScreenSaver extension to the new undocumented wallpaperextension format). I did move to "/Users/Shared" earlier this year but some people will inevitably get caught by this if they didn't update, and there's no recourse, FDA doesn't work, you can't even ask for access, nothing works. And since it's a silent fail, I didn't even notice before this week.
I think the issue comes in with terminal emulators and CLI harnesses. TCC permissions are inherited from the "responsible" process, so if you grant Terminal.app or ghostty.app FDA, you've granted zsh or bash or python or any goddamned thing you can run in a shell FDA.
Agree, I think for CLI harness, there is no good alternative, you either have access permit per terminal app (which is not ideal), or I guess that is what Apple means they will "address" it?
If that's the direction things are moving in, I welcome the change. Fine-grained folder access controls (rather than only full iOS-like sandboxing or full disk access) make me much less hesitant to try new apps or have agents access more parts of my system.
But they really need to solve the issue of low-level utilities triggering dozens of permission prompts when walking $HOME. Having to approve or decline Documents, Downloads, Google Drive etc. directory access, all separately, is extremely annoying.
I agree that this seems like a good thing. I really don’t need Firefox (or any app!) trying to check another app’s data without explicit permission.
... said that OpenAI security guy, no doubt.
However, it feels like one to the User. Having to get constantly prompted to grant permissions they don't even necessarily understand to random programs.
There's been chatter about how system like iOS are not "document based", they're app based. Many apps do not present their data as "files", users don't know where their data resides, just that the app knows and that's their window.
I don't know where an application on MacOS can "save their files" if they don't have "Full Disk Access". I don't know if they get some directory "for free" that they can use much like iOS does.
Then, of course, there's the Apple Document model where data auto saves to Somewhere. You have versioned files you can work with. But until you actually "save" the file to "the disk", its living in some unannounced space. My TextEdit app has dozens of "Untitled-XX" files that are...somewhere.
And its great! There's a peace of just having "stacks of stuff" that you can leave "unmanaged". "Where would you like to save your work?" "Oh, great, cognitive load just exploded as need to think about the minutia of data organization, when, mostly I just "don't want to lose this".
But, the constant prompting is exhausting, to me. Again, I have to "think about it". I need to question everything, when I really just want to Get Stuff Done.
And, in time, we become blind to these prompts. "ok, Ok, OK!! GO ALREADY! JUST WORK!!".
Exhausting.
That feature was so stupidly nonfunctional before. Some apps got stopped by it, others didn't. Often you'd be able to install an app from homebrew and it had full ride access to the disk, while App Store apps had to request consent for any folder whatsoever. It was completely random.
Personal assistants are realistic for very rich people because they can be paid an extravagant wage and punished for disloyalty. A personal assistant costing pennies to someone else, with access to data worth more than its salary, makes no sense.
Apple Intelligence is a great example of this. Everything can funnel up to Siri, but neither you nor any other app on your computer can see what is fed to it by all of the APIs that would provide it data. So anyone who adds support for it is enabling Apple to do their usual slow broken thing with Siri and not enabling any other way you might want to use software or AI with that data.
This has nothing to do with your access to the disk and everything to do with 3rd party deceiving unhindered access to everything about your life because you installed something like Muse.
2) You still have full disk access if you want
And so it ends up mattering to us what the rest of society gets in terms of software too.
The simple root/user separation has long since ceased to be secure because, on a desktop machine, all sensitive information is, by definition, accessible to the user; having root privileges ultimately offers little advantage when it comes to exfiltrating data.
"Extraordinary" is a funny word choice. It was completely ordinary for most of the history of personal computing that any app you ran under your normal user account could see everything you had.
(I'm not saying this is a bad thing. As long as they allow informed users to continue to do whatever they please, I'm all for it.)
I simply do not understand how Adobe manages to bypass every single toggle available there. I can block access to every folder on my computer but the moment I open any Adobe app, they recreate that goddamned folder.
Why? How? Fucking hell Adobe. It’s 2026, you just don’t store cache and setting files in the fucking Documents folder.
Granting terminal full disk access grants arbitrary scripts full disk access. There’s a lot you can do with ACLs and the permissions system, but it’s not reflected in the UI for settings.
Then there’s allowing access to documents, downloads, desktop, external disks. This should really allow the user to select a path or paths for applications, because these options are way too broad (especially external disks).
I would still like to see not only more granular permissions, but single use permissions. Once I grant iTerm access to Documents for whatever reason, it always has such permission. I would be nice to limit that to a single use, or a single harness session.
get out of my way.
Indeed, I run all dev tools including coding agents inside sandbox now
No, it grants scripts I run full disk access. Unvetted scripts do not run in my terminal, so there are no secret sub-processes either.
But your terminal shouldn't be accessing any files; you just need to be able to launch /bin/zsh or whatever you use as your shell. The shell needs to be able to access files, but its container doesn't.
Of course, you could go farther. For example, on OpenBSD, even /bin/ksh has been somewhat sandboxed; it can see most of the file system, but the things it can do have been limited:
if (pledge("stdio rpath wpath cpath fattr flock getpw proc "
"exec tty id", NULL) == -1) {Edit: I should say, the model it was created with (select a folder, all media in that folder is mirrored) requires such permissions. One could imagine designs that don’t.
Still does, at least on Windows. I use it all the time - I have a playlist with a mix of Spotify music, and music from my server.
The gap here in functionality is between 'single manually specified folder/file' and 'entire disk'.
Windows' Vista-era UAC protections have been bypassed through lolbins since the day of its inception (although officially UAC is not a security boundary according to MS) and apps like Ghostty might punch a hole through disk access controls in the same manner.
I think so.
I don't know where this "ownership" debate came from. My ownership of my machine depends on strict, broad + fine grained control over what third-party devs (who are not me) get to do with my machine. Our interests are incompatible and hostile, in an era where most "native apps" ship analytics and marketing SDKs, or are videcoded. If macOS didn't offer these controls I would run every apps in a browser where it's sandboxed. This isn't the 90s.
This change is a reaction to a viral story from a tech reporter who shipped all his texts to Meta without meaning to, which tells you there's a consent and transparency issue for nontechnical users. I don't think anyone in the industry has figured out a proper solution. Unless you never interact with nontechnical people, it impacts your privacy indirectly no matter what you do. Though as technical user I hope we can get more fine-grained control and auditing.
There are benefits to sandboxing F/OSS too, but most of what you describe there are problems with proprietary software published by for-profit corporations and have dramatically less applicability to anything else.
The idea that application A can just have full blown disk access and slurp up your tax returns or something was always a pretty crazy security posture. It just so happened that an honor system kind of almost sort of worked for a while.
You can’t really do an honor system when people are running artificial intelligence systems that have no concept of morality with full disk access.
Their problem is not lack of morality. It is simply being unreliable, untrustworthy and unsafe.
Sure. Do I have to reboot the machine and put in special commands in the UEFI? Will the next OS update then revert that on me anyway? Will they silo all the data on a per-app database, then make the machine unjailbreakable?
I have little confidence that I am still free to do this much longer.
Things that have no conceivable need to phone home just get it for the hell of it. Its basically Full Disk Access but for Network Access which is arguably equally problematic
this is a majority of macos users (including many who are "technical")
When I hopped onto the Linux bandwagon in the 1990's, the community was touting its amazing security because any damage done was compartmentalized to a particular account. (Of course, that ignores root escalations. Of course, few Linux users cared about that back then because it was an obscure operating system.) In contrast, Macintosh and Windows (non-NT) security was non-existent.
These days, I find increasing security measures both burdensome and restrictive. That said, it is also necessary. We have long left the era when one could trust supposedly reputable software vendors -- never mind random developers.
> Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users’ full knowledge and understanding.
If you think an app from (say) Facebook can be trusted with unrestricted access to your whole machine, you're at least a bit naive.
But I think the "new world" is, we are over stimulated (eg. agents ask us 'permissions' for a long command) so we might give a sudo not fully aware of it where a big bold UX message box after a 'pseudo' sudo would better catch our eyes.
So it seems this is about adding additional layers over already existing ones in a way?
It has been extended, but not in a way that non-technical users can really use.
Also, if you are really old, you may remember how unhappy people were when wheel group appeared, and not everyone could "su" to root anymore. Giving everyone root was supposed to be normal!
I’m with you on ownership, but push against signed code restrictions especially with bootloaders, and closed drivers.
You have to send the user to the system settings pane for it and have them manually toggle it on there.
It's hard to imagine how it could be more explicit than it is currently. I imagine they have something draconian planned.
That assumes it can be solved and even then it requires research, so you cannot know how much effort it takes to find a solution.
Also, and IMO highly likely, any solution will be unusable for mere mortals. i thin that’s why you are saying “(dis)pleasure” and “configuring SELinux […] is a real pain”
In fact, my pet peeve is why can't 1Password build in the ability to "remotely" approve something via the 1Password app? I'd get a push message, hit allow, and it does the negotiation in an e2e encrypted way.
Then I could approve something my agent needs when I'm not at the computer. Service Accounts are a crappy solution to be honest.
If you open a project using a devcontainer it prompts you to build one. As long as you install all the tools you need in it, it just works.
Orbstack is much nicer than Docker to host the containers.
This will allow programs like Spotify to only specify limited folder access while it’ll allow programs like Backblaze Backup To specify full disk access.
Why would that stop at your computer's network socket?
rcmd wants to read window titles. Allow? Deny?
Like just 15 minuts ago I opened Untappd likr a bazillion times before and were present with 15 screens of toggles and like 250 entities at least. There were at least 10 permissions to give the consent to track the things I do outside the app.
So not only a detailed reason for the permission wouldn't work, it wouldn't be implemented in the first place,
I mean, think about it: what would it mean if ls had a separate sandbox identity from the shell that spawned it? It would mean that any process on the system not entitled to read files from disk could get that entitlement by just fork/execing ls and parsing its stdout. That's not a security boundary that makes sense. ls doesn't read files - ghostty reads files, and ls is just its deputy.
I might be missing something but isn't this exactly what iMazing[0] is? I know I use it to backup my iPhone, for example.
It's still possible to back up an iPhone to a jailbroken computer, using roughly the same iTunes sync system that was available on iPods. For now.
https://irp.fas.org/nsa/rainbow/tg020-a.htm
What is the signficance now of this 1989 report?
Though, there is also a third type of Documents directory, the kind located at paths such as ~/Library/Mobile Documents/com~apple~TextEdit/Documents. This is part of iCloud Drive and is the same directory that you get in Finder by going to iCloud Drive -> TextEdit. Very confusing.
But we probably should not think "There are several ways using only the GUI to tell whether an app is sandboxed.".
Let's not be that OpenAI guy.
But yes, it's unfortunate that macOS sandboxes cannot be nested.
Terminal (and sshd) are special, in that they actually do end up with inherent transitive permission to their immediate intended child processes, as those children are nigh-unto universally (due to the entire idea of what terminals do) designed to be operated using text written to their input, which Terminal (and sshd) can man-in-the-middle.
But like, that doesn't generalize: it certainly (and obviously) is the case that I can have a process that is allowed to write files to disk that I would be happy to let you run even if I do not trust you to write to even those same files (as you will corrupt them), much less any file on my disk, as I merely need to trust that application to not give you the ability to do arbitrary writes.
The better idea here is that processes are their own form of encapsulation, and just because they can do something doesn't mean that they expose that functionality. You thereby must limit what tools can be used by a parent -- so almost no one gets a generic "exec" permission: you get a whitelist of tools and arguments you can utilize -- but the result doesn't look much at all like the permissions on subprocesses needing be a subset of the parent.
Actually, there’s another exception to my previous statement that I should have mentioned. For mitigations that are meant to prevent an attacker from turning memory corruption into code execution or code-execution-like control – such as restrictions on mapping memory executable (at least that’s one purpose for such restrictions), or memory map lockdown – the mitigations’ effectiveness doesn’t depend on whether they’re applied to children. Those mitigations are sometimes treated as part of the sandbox system, sometimes separate.
That assumes you're only defending against malicious code. Spawning children with limited functionality is a useful defense against non-malicious code being exploited by malicious data, even if those children have privileges the parent lacks.
macOS has had a capabilities model for over a decade called App Sandboxing. It would be entirely impractical to expect app authors to correctly declare their permissions up front and for users to audit them. Hence the permissions granted to sandboxed apps are pre-determined by the OS, and can be extended through explicit user interaction.