• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Sandboxing and calling Launchctl
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sandboxing and calling Launchctl


  • Subject: Re: Sandboxing and calling Launchctl
  • From: Mark Allan <email@hidden>
  • Date: Thu, 31 May 2012 11:35:06 +0100

On 29 May 2012, at 15:42, Mark Allan wrote:

> For anyone following, using temporary entitlements only gets rid of two of the four errors, so I still can't make scheduling via launchd work.
>
> sandboxd still spits out:
> 	launchctl(14634) deny job-creation
>
> and Xcode/run log still gives:
> 	launch_msg(): Socket is not connected
>
> Other than rolling my own scheduling and writing a helper app which runs constantly in the background, can anyone think of a way around this?
>
> Thanks
> Mark

OK.  After nearly a week of head-banging, I'm just about ready to throw in the towel, dump sandboxing and potentially the Mac App Store altogether.

I spent the best part of yesterday reinventing the wheel and implementing my own scheduling mechanism to put into a helper app which would run in the background constantly as a login item... the timing/scheduling bit works fine, but the helper app can't actually DO anything because it runs in a different sandbox from the main app!!  This means I can't access the user's preferences without a temporary entitlement, and can't access the resources within my main app at all.

My helper app sits in Main.app/Contents/Library/LoginItems/MainHelper.app and is launched (based on user prefs) by calling
	SMLoginItemSetEnabled((CFStringRef)[NSString stringWithString:@"<my app identifier>.helpername"], true)

I've tried giving the helper the same bundle identifier as the main app, but that doesn't work (as expected, but I wanted to try anyway!).

I've even tried getting the path of the helper app ([[NSBundle mainBundle] bundlePath]) and removing the last 4 path components to get the path to the main application and launching it via NSWorkspace, so that I could then launch my helper that way and inherit the sandbox, but sandboxd gives more permission violations when attempting to launch the main application.  I suspect that would have been cause for appstore rejection anyway!

I feel like I've missed something obvious, but I just can't see it.  Is there a way to make the helper app run in the same sandbox as the main app?

Many thanks for your help.

Mark


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Sandboxing and calling Launchctl
      • From: Alex Zavatone <email@hidden>
References: 
 >Sandboxing and calling Launchctl (From: Mark Allan <email@hidden>)
 >Re: Sandboxing and calling Launchctl (From: Mark Allan <email@hidden>)

  • Prev by Date: RE: NSXMLParser and initWithStream
  • Next by Date: Re: Managed Objects and Contexts
  • Previous by thread: Re: Sandboxing and calling Launchctl
  • Next by thread: Re: Sandboxing and calling Launchctl
  • Index(es):
    • Date
    • Thread