Just over a month ago, I reported a strange and frustrating problem. I wanted to write a logarchive to external storage, but no matter what I tried, macOS wouldn’t allow it from AppleScript, although it was perfectly happy to do so using an identical command in Terminal. I think that I have now realised why.

Although almost all log commands work fine as an admin user, the particular command in question, log collect, requires root privileges. That’s a protection not for security or the potential for the outcome to have serious consequences, but primarily because making a portable copy of the log could affect the privacy of the user (despite the log’s already deep privacy protection). It would actually make more sense now to fall back on the privacy controls in macOS rather than requiring root privileges, as there’s no equivalent to sudo to obtain ‘elevated’ privacy settings.

Normally, an app triggering a request for access to removable storage would result in a consent dialog, unless the user had already established their intent to allow that. In this case, when run in Script Editor or from another app, macOS can’t see the calling app in its Attribution Chain, so giving Script Editor or anything else Full Disk Access doesn’t alter anything.

In those circumstances, one way to work around this is to add the command tool itself to the Full Disk Access list. But that doesn’t work here, as each user controls their own Privacy settings in the Security & Privacy pane, and has no access to those for the root user. So whatever your personal privacy settings might be, they seem to be ignored once you sudo a command to run it as root.

The exception to this appears to be in Terminal, which can sudo successfully and those commands run with root privileges appear to inherit Terminal’s privacy setttings. This may be cast into TCC’s privacy database, perhaps. But the same doesn’t apply to Script Editor: when it (or any app other than Terminal) tries to run a script with elevated privileges, access is determined not by the calling user’s privacy settings but by those set for the root user.

There’s no command line or script access to the settings in the Privacy tab of the Security & Privacy pane, other than to remove items from the access lists. So a command tool which is running as root can’t add itself to any of those lists, neither can the user, even with the benefit of root privileges. This makes it impossible for anyone outside Apple to investigate this further, or to consider any workaround short of creating a whole privileged helper app, which isn’t a viable alternative for an AppleScript user.

The irony is that root privileges are often required by commands in order to protect the privacy of users.