launchd & SMJobSubmit concerns/questions

I am developing a framework that currently bundles a software updater tool that is launched in the background (which is not a launchd job currently but as a user app), and the tool and framework communicate to each other via CFMessagePort pairs.. The updater tool currently may use the old AuthorizationExecuteWithPrivileges() function if it has insufficient privileges to do a task. I am now interested in looking into adopting the NSXPCConnection APIs (which seem more trustworthy to me for IPC), and which means my updater tool now needs to be a launchd job. Replacing my usage of AuthorizationExecuteWithPrivileges() would be interesting too, but I'm not sure I will tackle immediately. (I am aware it's insecure and not well designed API).

My rationale for SMJobSubmit: because I'm developing a framework people are already familiar with, my understanding is that SMJobBless carries too much of a burden for setting up code signing requirements; the app using the framework doesn't even have to be signed for starters. The helper tool would also need to be inside the app bundle rather than inside the framework for SMJobBless. In addition, I am interested in one-time tasks - I am not interested in "adding a helper" to the system, or installing a tool that remains installed globally or needs to be uninstalled specially - polluting this for every app that uses the framework. The setup complexity is something I want to avoid and may cause other issues (eg: radar 20446733). Furthermore, I will not always want to run using the system domain, because the user domain will suffice much of the time, but I still need a launchd job for XPC, and would want one anyway for this kind of background task.

SMJobSubmit/Remove deprecation - The previous rationale was mentioned because an OS or two ago, these functions were marked deprecated but that has now been reverted in the docs, and in the headers may still be marked as going to be removed in a future OS. I would rather not use a function that can be removed in a future OS although I imagine that would break many apps - anyone have an idea of the inconsistent story around this?

> Also, the bundle identifier uses "EBAS" rather than "EvenBetterAuthorizationSample" because NSXPCConnection has problems with long service names on OS X 10.8.x (longer than 64 characters). [EvenBetterAuthorizationSample sample code]

Does this limit apply to Mach service names (eg: CFMessagePort too) in general? I guess I can't just use the target's bundle ID and expect it to be okay.

> You must not daemonize your process. This includes calling the

daemon

function, calling

fork

followed by

exec

, or calling

fork

followed by

exit

. If you do,

launchd

thinks your process has died. Depending on your property list key settings,

launchd

will either keep trying to relaunch your process until it gives up (with a “respawning too fast” error message) or will be unable to restart it if it really does die. [Apple docs]

Does this mean agents and daemons (or is it just daemons?) can't spawn other processes? Does this restriction still apply in my case, where I am only interested in one-off tasks. I don't want a job to be idly terminated, but if it is killed somehow, I don't want it to be restarted, and when it succeeds, it should be forgotten.

I am thinking of using the following key/values to do that. I also make sure to remove the job before submitting it via SMJobSubmit:

@{ @"EnableTransactions" : @NO, @"KeepAlive" : @{@"SuccessfulExit" : @NO}, @"LaunchOnlyOnce": @YES }

I am also interested in agents & daemons launching other applications via LaunchServices & fetching the current list of user applications, and how supported that is, as it seems to work over here fine (minus maybe having to link against AppKit, gah). My agent/daemon's lifecycle in particular is tied to the lifecycle of one of the user's running applications. So it can't persist for long if the user logs out for example.

My privillege model plan is just to use kSMDomainUserLaunchd (aka - an agent?) if the host process is running as a normal user, otherwise kSMDomainSystemLaunchd (aka - a daemon?) if the host process is being run as root. Although I am not going to tackle this now (and currently stick with AuthorizationExecuteWithPrivileges), I am curious in the future about the case of running as a normal user, and using authorization to pass kSMDomainSystemLaunchd:

* In this case, does the daemon tool's ownership permission need to be changed to root before using SMJobSubmit? I am suspecting not as this would be impratical. Should the tool not be group/world writable though according to the Apple docs? Should I be copying the daemon/agent out of the bundle somewhere else in any case?

* The dialog brought up by the authorization request for kSMRightModifySystemDaemons requests for adding a helper, which is a little unfortunate wording in my case for a run-and-forget job. Users may be kind of skepitical towards that. kAuthorizationRightExecute seems to have more suitable wording for my usage case but I don't think I can mix and match them? (Note: I am aware of kAuthorizationEnvironmentPrompt)

Thanks for any assistance.