In macOS 12 beta, launching helper app from sandbox app causes "User doesn't have permission to launch the app (managed networks)"

Question

stheophil_tc OP

Created Aug ’21

Replies 8

Boosts 0

Views 2.4k

Participants 4

In macOS 11 and before, a sandboxed application could launch an application outside the sandbox with

[[NSWorkspace sharedWorkspace] openApplicationAtURL: [NSURL fileURLWithPath: @“…”] configuration:[NSWorkspaceOpenConfiguration configuration] completionHandler:^(NSRunningApplication* nsrunningapp, NSError* nserror) noexcept {
}];

Or

-[NSWorkspace launchApplicationAtURL:options:configuration:error:]

In macOS 12, when I do the former to launch a helper application inside our own bundle the following is traced to the Console:

error	16:22:56.542768+0200	CoreServicesUIAgent	LAUNCH:Application launch of disabled, bundled executable is not permitted, so returning kLSNoLaunchPermissionError, <private>, status=-10826
error	16:22:56.542794+0200	CoreServicesUIAgent	LAUNCH: Launch failure with -10826/kLSNoLaunchPermissionErr <private>
error	16:22:56.543032+0200	CoreServicesUIAgent	LAUNCH: Launch failed in CSUI with error Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSLine=3787, _LSFunction=_LSOpenStuffCallLocal}
error	16:22:56.543292+0200	CoreServicesUIAgent	handle LS launch error: {\n    AppPath = "...";\n    ErrorCode = "-10826";\n}

And an error message “User doesn't have permission to launch the app (managed networks)” is shown to the user. This seems to be a problem with our helper app, because I can launch e.g. Microsoft Visual Code that way.

The problem occurs both in ad-hoc signed debug builds as well as properly signed and notarised release builds.

Is there anything we have to do differently for macOS 12?

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’21

This seems to be a problem with our helper app

As a general rule, if a beta seed of the OS has broken your app then your first step should be to file a bug about that. It’s possible that your app is doing something wrong here, but it also possible that the OS itself is misbehaving.

Make sure to include a sysdiagnose log. That’s absolutely critical for issues like this. See our Bug Reporting > Profiles and Logs page for more info on how to get that log.

Also, you might want to try testing this on a ‘clean’ machine, just in case the bug is being triggered by some state on your current test machine. For advice on how I test this sort of thing, see Testing a Notarised Product.

Please post your bug number, just for the record.

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

0

Answer 2

stheophil OP

Aug ’21

It turns out that there were two independent problems:

I had a configuration error at first so spctl didn’t verify the application originally. I have fixed that.

For reference, my Info.plist file declared CFBundlePackageType as BNDL instead of APPL.

Now, launching the application works as long as the application is in /Applications but it does not work when it is in any other (accessible) location, e.g., /Library/Application Support/...

The question is now, is this change intended in macOS 12?

0

Answer 3

DTS Engineer OP

Apple

Aug ’21

Now, launching the application works as long as the application is in /Applications but it does not work when it is in any other (accessible) location, e.g., /Library/Application Support/

There are two applications in play here — the app doing the launching and the app being launched — and it’s not clear from the above which you’re referring to. So, in the problematic case:

Where in app doing the launching located?
And where is the app that’s being launched?

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

0

Answer 4

stheophil OP

Aug ’21

The app that is being launched has to be in /Applications in macOS 12 and this is a change from macOS 11. In macOS 11, as far as I can see, it could be anywhere as long as that location was accessible by the user and the sandbox.

(The app that is doing the launching is always in /Applications anyway)

0

Answer 5

stheophil OP

Aug ’21

A few more additions that may help others. I will contact Technical support for further help.

The problem is not specific to macOS 12 beta, it already occurs in macOS 11.5.1
The rules for launching applications using launchApplicationAtURL: have become stricter in some (undocumented) ways

launchApplicationAtURL: always succeeds regardless of the location of the launched app if the user has previously launched the same app via a double click
launchApplicationAtURL: seems to work when the launched app is in a subfolder of /Applications and the launched app is properly signed
when the launched app is in /Applications but only signed with an ad-hoc certificate, launching still fails. This may be a bug.

0

Answer 6

MartinW OP

Aug ’21

I also encountered this issue with a helper app on macOS 11.5. My main app is sandboxed, codesigned, and notarized. I verified that's all in order using the codesign and spctl tools. I also used the xattr tool to verify that none of my apps or their files have the quarantine flag set.

The helper app is inside the main app's bundle. When the main app tries to launch the helper app via NSWorkspace I see these errors in the console log:

LAUNCH:Application launch of disabled, bundled executable is not permitted, so returning kLSNoLaunchPermissionError, <private>, status=-10826
LAUNCH: Launch failed in CSUI with error Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSLine=3762, _LSFunction=_LSOpenStuffCallLocal}
handle LS launch error: {\n    AppPath = "/Users/me/whatever/MainApp.app/Contents/MacOS/helper.app";\n    ErrorCode = "-10826";\n}

It doesn't seem to matter whether my app is stored in the /Applications folder or elsewhere. Launching the helper app always fails.

I can clear the problem by manually launching the helper app in the Finder. Once I've done that the main app can also launch the helper app programmatically. Unfortunately this isn't a very friendly solution for customers.

If there's any way to workaround this issue, or anyone learns any more information about this situation, I would be very happy to know.

0

Answer 7

stheophil_tc OP

Aug ’21

I am pretty confident this is the bug that Apple has acknowledged here: https://www.macrumors.com/2021/08/14/apple-to-fix-scanner-permission-error-on-mac/

1

Answer 8

MartinW OP

Aug ’21

Thank you for that link. That certainly seems like the same issue. That's a real shame, and it probably means there's nothing individual developers can do about this problem to workaround it. I hope that Apple deploys a fix soon, and back to Catalina, not just Big Sur.

0