Skip to main content
Solved

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

W
Forum|alt.badge.img+3

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!

Best answer by gregneagle

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.

View original
    Did this topic help you find an answer to your question?

    12 replies

    J
    Forum|alt.badge.img+24
    • jarednichols
    • Valued Contributor
    • 1892 replies
    • December 13, 2012

    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

    G
    Forum|alt.badge.img+10
    • gregneagle
    • New Contributor
    • 343 replies
    • Answer
    • December 13, 2012

    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.

    J
    Forum|alt.badge.img+24
    • jarednichols
    • Valued Contributor
    • 1892 replies
    • December 13, 2012

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

    W
    Forum|alt.badge.img+3
    • woggledog
    • Author
    • New Contributor
    • 5 replies
    • December 14, 2012

    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...

    F
    Forum|alt.badge.img+23
    • franton
    • Esteemed Contributor
    • 850 replies
    • December 14, 2012

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

    W
    Forum|alt.badge.img+3
    • woggledog
    • Author
    • New Contributor
    • 5 replies
    • December 14, 2012

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

    F
    Forum|alt.badge.img+23
    • franton
    • Esteemed Contributor
    • 850 replies
    • December 16, 2012

    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.

    P
    Forum|alt.badge.img+9
    • PeterClarke
    • Contributor
    • 202 replies
    • December 17, 2012

    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

    F
    Forum|alt.badge.img+23
    • franton
    • Esteemed Contributor
    • 850 replies
    • December 17, 2012

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

    P
    Forum|alt.badge.img+9
    • PeterClarke
    • Contributor
    • 202 replies
    • December 17, 2012

    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.

    B
    Forum|alt.badge.img+11
    • Bukira
    • Contributor
    • 415 replies
    • December 17, 2012

    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

    G
    Forum|alt.badge.img+9
    • gknacks
    • Contributor
    • 33 replies
    • December 18, 2012

    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 :-)

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings