Responsible process launch constraint not working as expected

Question

marcthielemann OP

Created 3w

Replies 3

Boosts 0

Participants 2

I wrote a daemon that is launched from the following plist in /Library/LaunchDaemons:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>MachServices</key>
	<dict>
		<key>com.mycompany.daemon.xpc</key>
		<true/>
	</dict>
	<key>Label</key>
	<string>com.mycompany.daemon</string>
	<key>Program</key>
	<string>/Applications/MyApp.app/Contents/MacOS/MyDaemon</string>
	<key>AssociatedBundleIdentifiers</key>
	<string>com.mycompany.myapp</string>
	<key>SpawnConstraint</key>
	<dict>
		<key>team-identifier</key>
		<string>XXXXXXXXX</string>
		<key>signing-identifier</key>
		<string>com.mycompany.myapp</string>
	</dict>
</dict>
</plist>

No I want to make sure the daemon can only be launched via xpc by MyApp and I embedded the following responsible process plist into the daemon:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>team-identifier</key>
	<string>XXXXXXXXX</string>
  <key>signing-identifier</key>
	<string>com.mycompany.myapp</string>
</dict>
</plist>

But as soon as the plist is embedded, macOS refuses to launch the daemon because of a launch constraint violation. As I read in the documentation, the process opening and xpc connection is the responsible process. So what I am doing wrong?

Thanks.

Answered by DTS Engineer in 794128022

As I read in the documentation, the process opening and xpc connection is the responsible process.

Really? Can you point me at the docs that suggest that?

One thing to watch out for is that you’re creating a daemon, and it doesn’t make sense for the process that opened the XPC connection to be the responsible process for a daemon because a daemon can service many clients.

If you’re building a daemon, use the techniques from this post to authenticate clients.

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

Boost

Answer 1

DTS Engineer OP

Apple

2w

Accepted Answer

As I read in the documentation, the process opening and xpc connection is the responsible process.

Really? Can you point me at the docs that suggest that?

One thing to watch out for is that you’re creating a daemon, and it doesn’t make sense for the process that opened the XPC connection to be the responsible process for a daemon because a daemon can service many clients.

If you’re building a daemon, use the techniques from this post to authenticate clients.

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

1

Answer 2

marcthielemann OP

2w

Hi @DTS Engineer!

If found this in the transcript of this video: https://developer.apple.com/videos/play/wwdc2023/10266

"When your app requests a connection to your XPC service, launchd spawns the XPC service and is the parent of that XPC service but your app is "responsible" for that XPC service.

If I am not mistaken, XPC service (with a lower "s") refers to an agent or daemon. Or is it just a spelling mistake and refers to a XPC Service?

Thanks again! Marc

0

Answer 3

DTS Engineer OP

Apple

2w

If I am not mistaken, XPC service (with a lower "s") refers to an agent or daemon.

I did use that convention at one point, but it was never officially ‘blessed’ by Apple [1] so I’ve moved on. I now use named XPC endpoint to describe what you get when a launchd daemon or agent accepts XPC connections via its MachServices property. See XPC and App-to-App Communication.

Anyway, from that preso’s context it’s clear that the speaker is referring to an XPC service, not a launchd daemon that publishes a named XPC endpoint.

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

[1] Because it’s way too subtle.

0