installing a SMAppService based LaunchDaemon from the command line

our app has a helper to perform privileged operations.

previously that helper was installed via SMJobBless() into the /Library/LaunchDaemons/ and /Library/PrivilegedHelperTools/

we also had a script that would install the helper from the command-line, which was essential for enterprise users that could not manually install the helper on all their employee's Macs. the script would copy the files to their install location and would use launchctl bootstrap system as the CLI alternative to SMJobBless(). the full script is here: https://pastebin.com/FkzuAWwV

due to various issues with the old SMJobBless() approach we have ported to helper to the new SMAppService API where the helpers do not need to be installed but remain within the app bundle ( [[SMAppService daemonServiceWithPlistName:HELPER_PLIST_NAME] registerAndReturnError:&err] )

however, we are having trouble writing a (remote-capable) CLI script to bootstrap the new helper for those users that need to install the helper on many Macs at once. running the trivial

sudo launchctl bootstrap system /Applications/MacUpdater.app/Contents/Library/LaunchDaemons/com.corecode.MacUpdaterPrivilegedInstallHelperTool2.plist

would just result in a non-informative:

Bootstrap failed: 5: Input/output error

various other tries with launchctl bootstrap/kickstart/enable yielded nothing promising.

so, whats the command-line way to install a SMAppService based helper daemon? obviously 'installing' means both 'registering' (which we do with registerAndReturnError in the GUI app) and 'approving' (which a GUI user needs to manually do by clicking on the notification or by going into System Settings).

thanks in advance!

p.s. we wanted to submit this as a DTS TSI, but those are no longer available without spending another day on a reduced sample projects. words fail me.

p.p.s. bonus points for a CLI way to give FDA permissions to the app!

Answered by DTS Engineer in 820500022
there must be a way to fully install apps … in a non-interactive way, especially for businesses.

Agreed.

In my experience folks who run managed sites really like installer packages, because MDM systems are good at running those. So, one option here is to repackage your app as an installer package, and have the installer package install the daemon like it would any other launchd daemon, that is, copy the launchd property list file to /Library/LaunchDaemons.

You don’t need a separate build of your app here; your launchd property list can reference the tool within your app via BundleProgram.

However, it might make sense for your app to be able to detect that it’s installed that way and disable its ability to update and uninstall the daemon. In a managed environment those operations tend to be the purview of the site manager.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

SMAppService is really intended to be used by apps; the clue is in the name (-:

I’m not 100% sure why you’re having this problem. Is that script you posted an example of what you were previously doing with your SMJobBless code? Or what you’re trying to do with your SMAppService code?

p.p.s. bonus points for a CLI way to give FDA permissions to the app!

No. The purpose of such privileges is to allow the user to control their Mac. Adding a way around that would defeat that purpose entirely.

Having said that, in a managed environment the site manager can configure some of these privileges via the com.apple.TCC.configuration-profile-policy payload, deployed via MDM.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

thanks for your reply here

SMAppService is really intended to be used by apps; the clue is in the name (-:

yes but there must be a way to fully install apps (even if they use SMAppService) in a non-interactive way, especially for businesses.

I’m not 100% sure why you’re having this problem. Is that script you posted an example of what you were previously doing with your SMJobBless code?

yes, as mentioned this script is what we were previously doing when the app was still based on SMJobBless.

now that the app('s helper) is based on SMAppService, how to install&approve the helper instead?

as written launchctl bootstrap system just errors out...

Having said that, in a managed environment the site manager can configure some of these privileges via the com.apple.TCC.configuration-profile-policy payload, deployed via MDM.

thanks, exactly what we need.

there must be a way to fully install apps … in a non-interactive way, especially for businesses.

Agreed.

In my experience folks who run managed sites really like installer packages, because MDM systems are good at running those. So, one option here is to repackage your app as an installer package, and have the installer package install the daemon like it would any other launchd daemon, that is, copy the launchd property list file to /Library/LaunchDaemons.

You don’t need a separate build of your app here; your launchd property list can reference the tool within your app via BundleProgram.

However, it might make sense for your app to be able to detect that it’s installed that way and disable its ability to update and uninstall the daemon. In a managed environment those operations tend to be the purview of the site manager.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

installing a SMAppService based LaunchDaemon from the command line
 
 
Q