macOS Security scoping/exception for Plug-in with External Helper app

We have run into a security scoping issue with the newer macOS releases (specifically macOS 11.6.x and macOS 12).

First and foremost, all of our code is signed and notarized. Our software is made of multiple parts and its mainly a plug-in for Adobe's software products (so its distributed outside of the app store).

When you install our software, during the installation process a helper app is also installed in addition to the plug-in for Adobe's software.

When the plug-in is invoked from the Adobe application the plug-in then launches an external helper that is installed in the Library/Application Support folder. The external helper app performs the brunt of the computation.

We use openApplicationAtURL to launch the faceless background helper app but with newer macOS releases sometimes it gets terminated after launching immediately. The user needs to double click it once from what we have observed. We suspect this is due to a macOS security scope (thats the only conclusion we can come up with).

This behavior never used to exist before (macOS 10.15 or earlier). This doesnt occur with all users but a handful of people and on newer macOS releases. We are wondering what can be done to solve this or what are we doing wrong? Do we need to file a bug report?

Up vote post of paul@recosoft Down vote post of paul@recosoft
789 views
Posted by
paul@recosoft
Reply
Add a Comment

Replies

There are a variety of potential causes for this. Let’s start with a simple question: How are you installing your software? Using an Apple installer package (.pkg)? Or something else?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Hi Quinn,

Absolutely yet. We use productbuild and pkgbuild to make our installer.

Posted by
paul@recosoft
Up vote reply of paul@recosoft Down vote reply of paul@recosoft
Add a Comment

Cool. That rules out a bunch of possibilities.

Earlier you wrote:

sometimes it gets terminated after launching immediately.

Can you elaborate on that? Does it generate a crash report? Is the FBA [1] started and then terminated? Or is it not started at all?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Faceless background application, for those not familiar with old school Mac terminology (-:

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Hi Quinn,

There is no crash report whatsoever. We know that the FBA is launched as we see it in the Activity Monitor and after a few seconds or so its terminated or quit (?).

One work-around we've asked our users to do is to add the FBA as a login item (so its launched automatically). And this work-around works but its getting difficult to tell users to do this as this odd behavior never existed before with macOS.

Posted by
paul@recosoft
Up vote reply of paul@recosoft Down vote reply of paul@recosoft
Add a Comment

We know that the FBA is launched as we see it in the Activity Monitor and after a few seconds or so its terminated or quit (?).

Interesting. It’s important to determine how far your FBA got into its launch cycle. To do this:

  1. Use the OS log API to add a log point to the start of main.

  2. Run Console.

  3. Set up a process name filter. To do this, post process:PPP into the Search box, replacing PPP with the name of your process.

  4. Enable Action > Include Info Messages and Action > Include Debug Messages.

  5. Start streaming.

  6. Reproduce the problem and look to see what gets logged. Specifically, look for the log point you added at the start of main and also look at the last things being logged by the process.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Thanks Quinn. Will proceed and let you know what we find.

Posted by
paul@recosoft
Up vote reply of paul@recosoft Down vote reply of paul@recosoft
Add a Comment

Hi Quinn,

We implemented your suggestions and got an extremely useful log of the specific calls that are failing and returning an error.

Our code is terminating as we fail to write some critical information into a file that is required by our code. We're looking into whether its a bug on our side or there are some change we have to implement.

Thanks.

Posted by
paul@recosoft
Up vote reply of paul@recosoft Down vote reply of paul@recosoft

  • Yay for progress!

    —
    eskimo
Add a Comment