Re: Sandboxing and calling Launchctl
Re: Sandboxing and calling Launchctl
- Subject: Re: Sandboxing and calling Launchctl
- From: Mark Allan <email@hidden>
- Date: Fri, 01 Jun 2012 09:33:10 +0100
Thanks Alex,
Thanks for your reply.
If you're talking about the com.apple.security.inherit entitlement, that only works for helper apps which are launched via fork/exec from the main application. When the helper app is launched by LaunchServices (via SMLoginItemSetEnabled) it crashes immediately as it can't inherit a sandbox from anywhere.
In a last-ditch attempt, I was trying to get around that by:
Have my helper app launch the main app at startup.
The main app could then launch a second helper (with com.apple.security.inherit entitlement) to do the scheduling.
Main app then terminates immediately.
The two problems with that approach are firstly, the sandbox wouldn't let the helper launch my primary app because it's in a different sandbox, and secondly, my understanding of forking is that even if I could do that, when the main app terminates, any process it forked also gets terminated doesn't it?
Mark
On 1 Jun 2012, at 02:30, 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