Re: Sandboxing and calling Launchctl
Re: Sandboxing and calling Launchctl
- Subject: Re: Sandboxing and calling Launchctl
- From: "Rick C." <email@hidden>
- Date: Sun, 24 Jun 2012 18:58:18 +0800
This helped me thanks! Unfortunately I wasn't try to launch my helper app via launchd so it was a bit different. But had to say thanks! :-)
rc
On Jun 1, 2012, at 9:30 AM, Alex Zavatone wrote:
> If you haven't watched the video for Session 204 - "App Sandbox and the Mac App Store" from the WWDC 2011 videos, there might be some info in there that will help you around the 9 minute mark.
>
> Search for the 2011 WWDC videos on developer.apple.com
>
> GL,
> - Alex Zavatone
>
> On May 31, 2012, at 6:35 AM, Mark Allan wrote:
>
>> 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
>
> _______________________________________________
>
> 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
_______________________________________________
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