Apple's war on their users continues apace

So in Apple's continuing effort to prevent me from accessing my own computer, Full Disk Access is up to some new arcane fuckery. I found that even though Emacs is on the list, I still wasn't able to open files that were on my Desktop and other places without first going to Terminal and doing this:

    open -a Emacs ~/Desktop
    open -a Emacs ~/Library
    open -a Emacs ~/Downloads
    open -a Emacs /Volumes/Time\ Machine/

and so on. After doing that once, I could access them again in the future. I have no idea where this is recorded, or what other directories I will find on the exclusion list in the future.

The latest one that I cannot figure out is that "crontab -" works from Terminal, but from inside an Emacs shell buffer it says,

    crontab: tmp/tmp.16124: Operation not permitted

Why can Terminal do things that Emacs can't and how do I fix that?

I tried doing that "open" trick with /tmp, /var/tmp, /private/tmp, /private/var/tmp, /private/var/at/tmp, ~/tmp... it's not one of those. You might think, "run crontab under dtruss to figure out what directory you need to authorize! You sweet summer child, dtruss hasn't been functional on macOS for roughly a thousand years.

Update: The fix is to give /usr/bin/ruby full disk access! You get full disk access, and you, and you, and you! Turns out that the Emacs startup sequence begins with a Ruby script that decides what executable to launch, so the topmost process is the one that counts.

Previously, previously.

Tags: , , , , ,

24 Responses:

  1. Dave5 says:

    Most of that lives in /Library/Application Support/ … you used to be able to delete it to get things back on track (it would rebuild from scratch)… these days it’s locked up tight

  2. Vincent Janelle says:

    Did you give emacs "full disk access" in the security and privacy -> privacy pane in system preferences?

  3. Adam says:

    This article about similar problems has a solution in the last third (something about Emacs on macOS being started by Ruby?!): Emacs on macOS, Part 2.

  4. badc0ffee says:

    dtrace is dead, but you can still use fs_usage

  5. Sam Bushell says:

    I’d appreciate it if you would file a bug report with clear steps to reproduce.

  6. db48x says:

    Have you ever revisited your decision to prefer OSX over Linux? You’ve reported far more CADT coming from Apple than I’ve ever noticed using my preferred Linux distro over that same period. (And I run with SELinux enabled, which can cause exactly this same kind of weird permission problems.)

    • jwz says:

      Yes. I used several different Linux desktop environments recently while testing XScreenSaver 6, and holy crap it's still such a dumpster fire.

      • db48x says:

        Hmm. I guess you just end up seeing more problems than the median user either way.

        • jwz says:

          No, I'm not talking about code integration issues, just basic functionality.

          If I see it more, it's because I haven't been letting Linux UIs boil me like a frog long enough that I think this shit is acceptable. Not just the complete lack of organization but basic shit like "oh it forgets my mouse tracking speed every time I log out." Here's where you say either "oh yeah I'm used to that" or "gosh that doesn't happen for me, have you reported a bug?"

          This shit is remedial and endemic.

          I've got no time for Baby's First Desktop Learning Experience and that's what Linux GUIs still are, after all these years.

          • db48x says:

            That’s exactly what I said. It sounds like whether you use OSX or Linux, you see more problems than the median user.

            Certainly I’ve never had it forget my mouse tracking speed when I log out. If I had, I would have filed a bug and/or fixed the problem.

            On the other hand my copy of Guix did stop working last week after a reboot; it now gets an SELinux denial when I run it. I had customized my SELinux rules significantly, but perhaps I didn’t make those customizations persistent. I should take some time this week to figure out what I did wrong there.

            We all see problems that are related to the specific details of how we use our systems.

            • jwz says:

              You're acting like "I want my the UI to remember the setting in the slider" is some weird problem that I came across because I use the system in some ... weeeeeird way. That's nonsense. These are default installs doing amateur bullshit right out of the box.

  7. The weird thing with Ruby only happens with the pre-built images from, which is documented here, but the documentation doesn’t tell you about all the weirdnesses like this it causes. If you build Emacs from source normally, you get a normal Mac binary. I build Emacs from source precisely because of this fuckery (which has also caused some other Emacs features like the menu bar to break in the past). Who knows what the guy who maintains those builds is planning when Apple drops Ruby from Mac OS, but hopefully it’ll just go back to being a regular binary file with no wrapper script.

  8. Yngmar says:

    I remember when Mac OS X was cool because it had all that Unix stuff under the hood but with a decent UI on top. Now it has neither :-/

    • tfb says:

      Entertainingly I've just also upgraded from 10.14 to 11.whatever and ... none of this happens for me. I granted the Emacs application full disk access and it is entirely fine. It just might be because I always start it from a terminal (well, iTerm) window which also has full disk access, but it ultimately gets run by 'open -a /path/to/ ...` so, I don't know.

      Perhaps full disk access is somehow cumulative: if I've granted this application full disk access and I'm running it from a shell within another application with full disk access then I really, really mean it, and the thing will get out of the way. Probably if you nest it three deep it grants you raw disk access or something.

      Alternatively perhaps there's a conservation law: I get Emacs working, but is, um, amusing to watch, and Firefox (I know) is mostly catatonic.

      • jwz says:

        Yes, FDA applies to the top of the process group in the bundle that launched it, in your case Terminal. If you launched Emacs from Finder, the top process would be Emacs's ruby launcher instead.

        • tfb says:

          That makes sense. What doesn't make sense is why, when you grant something FDA, it doesn't just find the executable thing it runs, and mark that. The idiot counterargument would be that it can only do that if it's signed. But that's bogus because I know for a fact that you can mark random unsigned binary executables as having FDA, because I have a whole mechanism for cron jobs built around exactly that trick. So why was it too hard for it to mark the ruby script as OK? It could even mark it OK only if some cryptographic checksum didn't change which would require you to re-anoint it every time the script chsnged (so, probably, never).

          Clearly I am just too stupid to understand the vast guiding genius behind all this.

  • Previously