Launchctl unable start service with error 0x1 - Operation not permitted after app signing updated

Question

Created Mar ’24

Replies 2

Boosts 0

Participants 2

Hi, we are working on an application which will perform scheduled backup tasks in macOS 14. The app has been granted full disk permission.

Recently we updated the code signing for the executable (/Applications/MyApp.app/Contents/MacOS/MyApp below) for passing the new notarization.

After that, we found launchctl unable to load the plist for the schedule job

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
	<key>Label</key>
	<string>com.MyApp.scheduler</string>
	<key>ProgramArguments</key>
	<array>
		<string>/Applications/MyApp.app/Contents/MacOS/MyApp</string>
		<string>/Applications/MyApp.app</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
	<key>AbandonProcessGroup</key>
	<true/>
	<key>WorkingDirectory</key>
	<string>/Applications/MyApp.app/bin</string>

</dict>
</plist>

Related error message found in /var/log/com.apple.xpc.launchd/launchd.log*


2023-12-13 13:59:34.639672 (system/com.MyApp.scheduler [13434]) <Notice>: internal event: SOURCE_ATTACH, code = 0
2023-12-13 13:59:34.644530 (system/com.MyApp.scheduler [13434]) <Error>: Service could not initialize: posix_spawn(/Applications/MyApp.app/Contents/MacOS/MyApp), error 0x1 - Operation not permitted
2023-12-13 13:59:34.644545 (system/com.MyApp.scheduler [13434]) <Error>: initialization failure: 23C64: xpcproxy + 38300 [1097][925DE4E7-0589-3B33-BB64-7BC2F8629897]: 0x1
2023-12-13 13:59:34.644548 (system/com.MyApp.scheduler [13434]) <Notice>: internal event: INIT, code = 1
2023-12-13 13:59:34.644915 (system/com.MyApp.scheduler [13434]) <Notice>: xpcproxy exited due to exit(78)

We have tried to update the entitlements for library and main executable files while still not success on make it works again. We have no idea what else could do for troubleshooting this.

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
    <key>com.apple.security.cs.debugger</key>
    <true/>
    <key>com.apple.application-identifier</key>
    <string>...</string>
    <key>com.apple.developer.team-identifier</key>
    <string>...</string>
</dict>
</plist>

Appreciate for any suggestions. Thank you.

Boost

Answer 1

DTS Engineer OP

Apple

Mar ’24

<key>WorkingDirectory</key>
<string>/Applications/MyApp.app/bin</string>

Nothing good can come from this. For a macOS-style ‘deep’ bundle, the only thing supported at the root of the bundle is Contents. Relocate this stuff deeper into your bundle.

For specific advice on how to structure your bundle, see Placing Content in a Bundle.

As to your main problem, I have three comments:

Your app is claiming restricted entitlements. These must be authorised by a provisioning profile, and the profile must be of the right type. So, if you re-sign your app for Developer ID, you must change the embedded profile to match. See Creating distribution-signed code for macOS for more about manually re-signing apps.
I recommend that you not use Developer ID for day-to-day signing. That’s because Developer ID code-signing identities are precious. See The Care and Feeding of Developer ID. Use Apple Development signing for day-to-day work.
Try to avoid mixing Apple Development and Developer ID signed code on the same Mac. When it comes time to test your release build, do that on a machine that’s never seen your Apple Development build. I generally do this on a VM, restoring the VM to a ‘clean’ snapshot between each test. See Testing a Notarised Product.

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

0

Answer 2

annng OP

Mar ’24

Thank you for your suggestions.

We have now moved the files to under Contents/Resources/

For entitlement we attempted to remove all from the file to isolate the issue, and removed provisioning profile to avoid mismatches.

<plist version="1.0">
<dict>
</dict>
</plist>

This still result in same results of "Operation not permitted' Is the provisioning profile always required?

btw, do we have more things to check for what operations was being not permitted? Thanks

0