> What permissions should sh get, for example? The permission model works pretty similar here to a restricted user account. It sees system files as read-only,

> What permissions should sh get, for example? The permission model works pretty similar here to a restricted user account. It sees system files as read-only, cannot see the contents of certain files and directories, etc. The root of the filesystem might be of the parent system or of the sandbox itself. On macOS, reading certain directories (like the user's Desktop) will result in a user consent prompt due the sensitive contents. There is, after all, no guarantee that the request was directly initiated by the user, and not some curl-pipe shell script. There is however a "Developer Tools" entitlement that encompasses all of these sorts of prompts - but this is meant to be enabled through a developer action and not any user-presented prompt. On macOS, there are basically higher-than-root system integrity protections, such as modifying files that the OS maintains. You can disable this system protection by booting into recovery mode and running a command-line tool. Generally, the goal with system integrity protection is not to restrict professional work but to restrict the ability to publish software that tells the user to disable system-wide protections. There was recently an issue with the Google installer where a Chrome update wiped out part of the system when these protections were disabled, primarily noticed on hackintoshes and video production Macs where tools require SPI to be disabled to run unsigned kernel extensions, etc. Oops. Apple has been trying to reduce the need across macOS releases to have applications need to be installed at all, with recent releases making items like browser, system, and kernel extensions bundled inside the application itself rather than being distributed across the filesystem. The goal is likely to eliminate app installation on macOS from needing to be a privileged operation.