Start App from script that's run as Launch Daemon (root)

[woggledog]

Morning all. I have what I feel should be a simplistic request that's troubling me.

I'm running a Launch Daemon (that ultimately runs as root, as all launch daemons do) that calls an applescript. That's running fine.

The applescript, at some point, may need to launch an app. These are the methods tried:

tell application "VerifyAndChangePassword" to launch

this fails with: /usr/bin/myscript.scpt: execution error: An error of type -10810 has occurred. (-10810)

do shell script "open -a /Applications/myapp.app"

fails with: /usr/bin/com.bob.myscript.scpt: execution error: LSOpenURLsWithRole() failed for the application /Applications/VerifyAndChangePassword.app with error -10810. (1)

any ideas? I may have to write a launch agent that monitors a plist and launches the app from there instead!

[jarednichols]

10810 can occur if your process table is full. You may have a runaway process somewhere preventing it from launching. Have a look at this: http://www.thexlab.com/faqs/error-10810.html

[gregneagle · Accepted solution]

This sounds like a similar structure as I have in Munki (http://code.google.com/p/munki) in that there is a background process, running as root, that sometimes needs to launch a GUI application in the current user's context.

I, too, originally used variations of /usr/bin/open and the like. Under Leopard, this worked fine, but under later versions of OS X I started getting errors similar or identical to those you are seeing.

I eventually wrote a LaunchAgent that simply used KeepAlive/PathState to watch for a certain path. My root process would then create that file when it wanted to launch the GUI app. The LaunchAgent would see the file, and launch the app in the user's context.

A similar approach should work for you, I'd think.

[jarednichols]

This was my other thought along with Greg: sandboxing between root and user contexts.

[woggledog]

In frustration, I did something something similar Greg.... Wrote to a plist which a Launch Agent monitored for a particular flag (that was set by the launch Daemon)

Then I remembered that I was only using the LD for historical reasons: Moved it over to a launch agent and it worked first time

Thanks for the responses guys...

[franton]

Fairly sure that behaviour is intentional by Apple for security reasons. Does your AppleScript really need to run as root?

[woggledog]

Not any more, hence the reason to move to Launch Agent not Daemon

[franton]

I meant that Apple is being paranoid with Applescript for some reason. I've had to do weird and nasty things with privilege escalations in the past (thankfully no longer needed today), to get Applescript to do certain tasks.

[PeterClarke]

You can run an AppleScript - with admin privileges, effectively it runs as sudo

The Applescript has to be owned by admin.

To be honest, I have never needed to do this…,but then I've not tried to do exactly what you are trying here…
There may well also be other ways to do that operation.

do shell script "ScriptHere" with administrator privileges -- would prompt for admin username and password.

or use

do shell script command user name "adminusername" password "password" with administrator privileges

In which case you are not prompted for the username and password
-- but the downside to this is that the admin username and password is now visible in plain text… in that script !!
-- You could make the scrip an run-only app (keep a backup copy is text format - for any future editing)
-- That may offer one way around that.

-- Regards -- Peter

[franton]

Exactly! Hard coding in plain text admin passwords is not good practice!

[PeterClarke]

Which is why - if that method is used, I suggested making it a Run-Only application
– since then the passwords would be hidden and unreadable in the compiled binary…

But then if you later needed to make some change (perhaps the password has changed) or some other change
- that Run-Only application is NOT editable…

Which is why a backup (NOT deployed) plain text copy is also needed - so that you could re-edit it, and resave. and resave a copy again as a Run-Only application.

That's not to say that this is the best was of solving to overall problem - but it is one solution.

[Bukira]

Write it in objective-c in XCode and build your own comandline binary that when run launches and Application via name, then use a luanchdaemon or agent to run the commandline binary

[gknacks]

Passwords are still saved in plain text in Run-only apps/scripts. Right click>Show package contents, and poke around in the text files and you'll find it :-)