![]() I did some more testing and can't seem to give any normal† program full disk access anymore. Script := filepath.Join(dir, "restic-backup.sh")Ĭmd := exec.Command("/usr/local/bin/bash", script)įor security, I sudo chown root and sudo chmod 0700 the resulting binary before adding to Full Disk Access (although admittedly an attacker could just change the bash script that this calls if it were left unprotected). Add to the root-owned /Library/LaunchDaemons plist, and you have a way to call it from root without all the craziness above.Įxample script in Go: // Runrestic provides a binary to run my restic backup script in MacOS Mojave with Full Disk Access Add that binary to FDA and it seems to work. Reload launchd script with launchctl and test to make sure it seems to be workingĪfter some preliminary testing, it looks like a slightly less hacky workaround is to compile a binary (using a compiled language) that calls your bash script.Change my launchd script to open /path/to/MyApp.app.Change the AppleScript to do shell script "sudo -n /path/to/myscript.sh" and resave as MyApp.app.sudo chmod 0740 myscript.sh (4 so it can still be added to VCS).myuser ALL=(ALL) NOPASSWD: sha256:hashgoeshere /path/to/myscript.sh) sudo visudo and give my unprivileged user the ability to run my backup script as sudo with NOPASSWD: (I also specify the hash of the script to hopefully improve security, e.g.One option for this is to add with administrator privileges in your AppleScript, but this requires manually typing in your password, defeating the purpose of automated backup. (I'd be happy to open this as a separate question if appropriate, since I think the below workaround leaves much to be desired.) to back up root-owned 0600 files), you're in for another set of hacky workarounds, since /usr/bin/open won't seem to run anything as root (even if you specify the UserName key in in a root-owned /Library/LaunchDaemons/ plist. If your backup script needs root access (e.g. So if you didn't do this, remove your app from FDA, save and close Script Editor, then add back to FDA.įor your LaunchAgent, use something like: /usr/bin/open NB: If you didn't save and close Script Editor prior to adding to FDA as instructed, it seems that some kind of invisible process (automated background saves?) will change something (some kind of timestamp or hash?) that is required for Full Disk Access, which can some intermittent errors that were a major headache to figure out. MyApp.app/Contents/Resources/)įor Step 1, you can easily package your script as an app by using tools built into MacOS such as Automator.app or Script Editor, or Platypus also works.Įxample contents of such an app might be a simple AppleScript (in Script Editor) such as: on runĭo shell script "/usr/local/bin/bash /path/to/myscript.sh"įrom Script Editor, use the dropdown in the save menu to save as an application, then CLOSE SCRIPT EDITOR.Īdd this app to Full Disk Access through System Preferences -> Security & Privacy. app (either by double clicking via GUI, or open /path/to/MyApp.app but not by directly using the executable stored in e.g. ![]() ![]() Package a standard MacOS application that runs a script (a bash script in my case, which in turn sets up an environment and runs a separate binary that requires FDA).The original binaries I created with this method continue to work without errors for some strange reason, but I can't give access to new binaries directly using this method. Update 20190226: As detailed in the Restic issue linked below, this seems to have stopped working. Update: Slightly less hacky workaround below. My solution is a totally hacky workaround, but doesn't require whitelisting bash entirely. I agree that the currently accepted answer is not really a solution - it's not much better than just disabling SIP altogether. I've spent a few weeks trying to sort this out.
0 Comments
Leave a Reply. |