Can't attach debugger to a helper application with com.apple.security.inherit

Hello,

I have sandboxed mac app which is launching a helper app. The main app has sandbox enabled and has get-task-allow entitlement. From main app I launch[1] a helper which is an application bundle located in Contents/Helpers of the main bundle. The helper has sandbox enabled and com.apple.security.inherit entitlement.

Currently I have a problem attaching debugger to helper process or getting access to location services from it (but that's probably different issue). I checked the responsible process and it seems to set up to correct PID of the main application.

The Xcode is reporting "Not allowed to attach to process" error and I see the same in the log:

macOSTaskPolicy: (com.apple.debugserver) may not get the task control port of (com.****) (pid: 31628): (com.****) is hardened, (com.****) doesn't have get-task-allow, (com.apple.debugserver) is a declared debugger(com.apple.debugserver) is not a declared read-only debugger

To add a more of the context what I'm trying to achieve is that we run certain parts of our app in separate child processes so we can restart then if anything goes wrong [2].

So I have few questions:

  • Do I need to launch the helper (child) process a particular way to be able to attach debugger to it?
  • Is there a tool to inspect sandboxes (rules applied and the inheritance)?
  • Do I really need to explicitly enable sandboxing and inheritance on the helper app, doesn't it run in the parent' s sandbox anyway?

Thank you.

  • [1] We use boost::child_process for launching the helper, which is using popen behind the scene, but I have the same experience with NSTask.
  • [2] I know that's what XPCServices are for but don't ask :-)
Up vote post of isnotgoodms Down vote post of isnotgoodms
834 views
Posted by
isnotgoodms
Reply
Add a Comment

Accepted Reply

Thank you @eskimo for quick answer :-)

Please post your bug number, just for the record.

Here it is FB13136758.

If removing these entitlements helps with this problem — and I’m not 100% sure it will (...)

It does help because I can then explicitly add com.apple.security.get-task-allow which will otherwise prevent the helper from starting if com.apple.security.inherit is present. Not sure if this is bug or feature :-) The docs are clear that any other entitlement than those two for sandbox inheritance will abort the application start but that is not entirely true already.

For anyone having the same problem: Solution for me wast to remove the com.apple.security.app-sandbox and com.apple.security.inherit and add com.apple.security.get-task-allow so I can debug the helper which will still be running in parent's sandbox. For production builds I reverse that and it should work for Mac App Store too hopefully without any unexpected side-effects.

Posted by
isnotgoodms
Up vote reply of isnotgoodms Down vote reply of isnotgoodms
Post marked as solved
Add a Comment

Replies

Do I need to launch the helper (child) process a particular way to be able to attach debugger to it?

There’s no such mechanism.

Is there a tool to inspect sandboxes (rules applied and the inheritance)?

I wish!

I’d appreciate you filing an enhancement request for this. There’s a lot of internal infrastructure for this sort of thing, but none of it’s available to third-party developers.

Please post your bug number, just for the record.

Do I really need to explicitly enable sandboxing and inheritance on the helper app, doesn't it run in the parent’s sandbox anyway?

That depends on your distribution channel. The Mac App Store requires that all executables be sandboxed, meaning they must have the com.apple.security.app-sandbox entitlement. That tries to set up a new sandbox by default, which is why you need com.apple.security.inherit.

Outside of the Mac App Store you don’t need either of these and child processes get sandbox inheritance by default.

If removing these entitlements helps with this problem — and I’m not 100% sure it will — that suggests an easy workaround: Remove them while you’re debugging and re-instate them for releases you push to the Mac App Store.

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

Thank you @eskimo for quick answer :-)

Please post your bug number, just for the record.

Here it is FB13136758.

If removing these entitlements helps with this problem — and I’m not 100% sure it will (...)

It does help because I can then explicitly add com.apple.security.get-task-allow which will otherwise prevent the helper from starting if com.apple.security.inherit is present. Not sure if this is bug or feature :-) The docs are clear that any other entitlement than those two for sandbox inheritance will abort the application start but that is not entirely true already.

For anyone having the same problem: Solution for me wast to remove the com.apple.security.app-sandbox and com.apple.security.inherit and add com.apple.security.get-task-allow so I can debug the helper which will still be running in parent's sandbox. For production builds I reverse that and it should work for Mac App Store too hopefully without any unexpected side-effects.

Posted by
isnotgoodms
Up vote reply of isnotgoodms Down vote reply of isnotgoodms
Post marked as solved
Add a Comment

Here it is FB13136758.

Thanks.

Not sure if this is bug or feature :-)

Yeah, you and me both (-:

The docs are clear that any other entitlement than those two for sandbox inheritance will abort the application start but that is not entirely true already.

Right. The App Sandbox startup code has an allowlist for entitlements that are compatible with com.apple.security.inherit. We’ve recently added a number of entitlements to that allowlist, most notably a bunch of the entitlements associated with the hardened runtime. IMO that’s worthy of two additional bugs:

  • The docs should describe that allowlist, rather than saying it’s restricted to just those two entitlements [1].

  • I think it’s reasonable to argue that com.apple.security.get-task-allow should be allowed to facilitate debugging. If you agree, make your case in a bug report.

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

[1] To be fair, if you search DevForums you’ll find plenty of posts by me that promulgate this mistake. I’ve only learnt about this subtlety in the last few years.

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

I think it’s reasonable to argue that com.apple.security.get-task-allow should be allowed to facilitate debugging. If you agree, make your case in a bug report.

Agree, suggested that in case FB13163106, hopefully someone finds it out worth of implementation :)

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