Why a bash script ran directly doesn't need user permissions, but a .app file running the script needs them?

Question

I have a bash script myscript that loads some applescript to prompt a graphical interface to the user, to ask for his password.

• If I run the bash file directly, outside of a .app bundle, it can do it without the system prompt do you want to allow this program to access...[stuff]?

• But if I put the same bash file inside a .app bundle (with the same name as the script), and double click the .app file, then it will first show the system prompt to ask for user authorisation. I have added no special entitlements to the app.

Is there a link that explains how a .app security is different for executing a script as opposed from the command line?

Answer 1

In both cases the script is being launched by an app. In one case that app is Terminal, and it has the required permissions. Your app doesn't at this point.

This is a change in 10.14, described in the release notes:

Sending Apple events from an app—including script applets—now requires user approval. The list of currently approved apps can be viewed and edited in the Automation category in the Privacy tab in System Preferences > Security & Privacy. If an event is blocked because the user didn’t approve that app, the event will fail with the error code: -1743 (": Not authorized to send Apple events to "). An event can be preflighted using AEDeterminePermissionToAutomateTarget(::::).

Mojave has introduced very stringent controls around Apple Events (the core of AppleScript), which has greatly complicated automation. Michael Tsai has aggregated a lot of helpful discussion of the issues.

See also: com.apple.iTunes AEDeterminePermissionToAutomateTarget is always return -600