Problem with startup helper crash once sandboxed with App Wrapper

Today I encounter a problem with the VDSC helper I have been using for a couple years, which launches an app at startup. It worked like clockwork until today, and I am at a loss finding out what is going on.

When non sandboxed it works just fine. It runs as well in the IDE. But when sandboxed into the application, it crashes apparently right off the bat (no debug message in Console).

Here is the crash log.

From the little I understand, the sandbox is not happy :

[code]Sandbox registration failed: Process is not in an inherited sandbox.

Application Specific Signatures:
Registration error: Process is not in an inherited sandbox.[/code]

It must be something simple, but I have to confess puzzlement.

Pointers will be appreciated.

OK. It seems the issue comes from the way App Wrapper signs files inside the bundle.

When I wrap the entire app containing the helper, the main app works, but the helper becomes unusable.

If I wrap the helper by itself, it remains functional.

So there is something in the deep signing process that damages the helper.

I could not find any settings as there used to be to choose between --deep and Ohanaware signing method.

Unless I am mistaken, for the MAS all files inside the main app bundle must be signed identically, so I fear signing the helper separately then integrating it into the wrapped app will get my app rejected.

By default App Wrapper doesn’t use --deep, you can enable it by selecting Apple Temporary option in the popover that appears from the action icon next to the code signing identity selector.

App Wrapper uses its own version of deep.

What I’d suggest checking is that inheritance is selected on the capabilities pane.

The inheritance is checked.

I will run some more experiments and report.

Thank you Sam.

Valdemar De Sousa made a sample app and gave a lecture on the subject at Koblenz '14 conference.

Helper app and main app are required to use the same sandbox, otherwise it won’t work. They need to have the same Bundle Identifier for that.

[quote=267995:@Oliver Osswald]Valdemar De Sousa made a sample app and gave a lecture on the subject at Koblenz '14 conference.

Helper app and main app are required to use the same sandbox, otherwise it won’t work. They need to have the same Bundle Identifier for that.[/quote]

Yes, I am doing all that. I had been using VDSC back then, but since, there have been changes in sandboxing that seem to have broken the helper. I am sure with Sam’s help it will be alright. Just have to find the proper settings.

I switched to Apple Temporary and that did the trick.

With the default, App Wrapper reported that the helper was modified at cleaning time.

All I can say is “Huh?!”. Is there somewhere I can take a look at the application?

I just sent you an email :slight_smile:

Okay, I was thinking about this whilst walking the dogs this morning, and I haven’t yet looked at your e-mail.

Backup To Go uses a launchitem (/Contents/Library/LoginItems/ and this is code signed separately from the Backup To Go bundle. It has one entitlement which is the “” with the value of true.

In the Backup To Go App Wrapper settings, under the “Other” pane, it’s been specified to be ignored.

This allows the OS to launch the helper at user login, but it does prevent the main application from using a shell or NSTask to launch the helper. Instead it has to be launched with.

declare function SMLoginItemSetEnabled lib "ServiceManagement" ( identifier as CFStringRef, value as boolean ) as boolean

So I think it was working correctly, but it sounds like you’re trying to launch it form the main application, which is not permitted.

I think Sam is right, I am using this code (MBS) to launch the helper in a sandboxed app:

// Enable a helper application located in the main application bundle's // Contents/Library/LoginItems directory If ServiceManagementModuleMBS.LoginItemSetEnabled(hlp.BundleID, True) Then // Registers or updates a helper application in the Launch Services database Call ServiceManagementModuleMBS.RegisterHelperApp(hlp.helperName, True) Return True End If

Thank you Sam and Oliver.

The helper does only one thing, is to launch the main app ; not the other way around.

It seems to work just fine as it is, but I do appreciate the snippet. I will report as I go along until submission to the MAS. As I mentioned above, I did submit successfully before using exactly the same file structure and default sandboxing from App Wrapper. So I should be alright.