- 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.
Most of that lives in /Library/Application Support/com.apple.TCC/TCC.db … 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
Did you give emacs "full disk access" in the security and privacy -> privacy pane in system preferences?
Yes, I said that.
Best guess without using Emacs is that the Emacs shell buffer is launching a different binary in the background. If you run `sleep 60` and us pstree or equiv. you may see it. That binary, whatever it is, would also require the same `open -a` commands run on it. If not that, then I'm stumped.
The program that the shell buffer is launching is... my shell. The same one Terminal launches.
Is there any intermediary? For instance, at https://gist.github.com/dive/f64c645a9086afce8e5dd2590071dbf9 they talk about how Emacs uses a ruby script to launch (??) so full disk access is also needed for /usr/bin/ruby. I believe the issue is that permissions are inherited, so if a given binary is launched by something that doesn't have full disk access, it can't have it either (preventing un-authorized things from privilege escalation?). If Emacs uses a script to launch your shell, then??? :-/
You're right! It looks like adding /usr/bin/ruby to Full Disk Access fixed the crontab problem!
Sweet. There's a decent chance that having "Emacs" granted full disk access via the GUI will now do the right thing as well, obviating the need for all the `open -a` commands next time you re-install.
The gory details: https://github.com/caldwell/build-emacs/blob/master/launch.rb
That could have been a statically built binary with effectively no dependencies.
The ruby access issue was reported more than a year ago on that github repo but apparently ignored.
https://github.com/caldwell/build-emacs/issues/94
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.
dtrace is dead, but you can still use fs_usage
I’d appreciate it if you would file a bug report with clear steps to reproduce.
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.)
Yes. I used several different Linux desktop environments recently while testing XScreenSaver 6, and holy crap it's still such a dumpster fire.
Hmm. I guess you just end up seeing more problems than the median user either way.
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.
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.
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.
The weird thing with Ruby only happens with the pre-built images from EmacsForMacOS.com, 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.
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 :-/
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/Emacs.app ...` 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 Mail.app is, um, amusing to watch, and Firefox (I know) is mostly catatonic.
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.
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.