Hi Folks,
We are reading the USB device data from our app using libusb/iokit libraries.
Before updating the MacOS to the 15.3 we never faced any issue but after updating OS to 15.3 Sequoia we started facing issue to access the USB device's information.
We are not getting the device endpoints for the matching service and fails with below error-
Error:Failed to create IOUSBHostObject. with reason: IOServiceOpen failed.
Respective code snippet-
service = IOServiceGetMatchingService(kIOMasterPortDefault, matchingDictionary);
IOUSBHostInterface* interface = [[IOUSBHostInterface alloc] initWithIOService:service
options:IOUSBHostObjectInitOptionsDeviceCapture
queue:*queue
error:&error
interestHandler:nil];
We get the denial message during accessing the IOService
error 23:17:30.691934-0800 kernel 41 duplicate reports for Sandbox: spotlightknowledged(1399) deny(1) mach-lookup com.apple.diagnosticd
error 23:17:30.691945-0800 kernel System Policy: com.prograde.pgdrefreshpro.helpe(70515) deny(1) iokit-open-service IOUSBHostInterface
Also when we checked the IOUSBHOST logs we can see pipes are stalled while running the RefreshPro app as below-
2025-02-05 22:06:31.838141-0800 0x25913e Error 0x0 0 0 kernel: (IOUSBHostFamily) AppleUSBIORequest: AppleUSBIORequest::complete: device 8 (SD PG05.5@08210000) endpoint 0x00: status 0xe0005000 (pipe stalled): 0 bytes transferred
We need an assistance here to know what exactly could be the cause and how can we elevate the permissions to access the USB device on MacOS15.3.
Do we need other entitlements? As we never faced such issue with our certificate and Identifier on any MacOS versions and with the current entitlements we have.
Do we need to include any entitlement in the code?
Thanks.
We spent some time to create a provisioning profile which contains all these entitlements but are struggling here.
Sorry about that, this was my mistake. Quinn reminded me that the "com.apple.security.*" macOS entitlements are unrestricted, which means they're just added directly to the executable entitlements and are not included in the provisioning profile
So, going back to the beginning of things, I have a new guess as to what's going on here. The "core" error here is the kernel denying access:
2025-02-18 16:53:39.489770+0530 kernel: (Sandbox) System Policy: <bundle ID> (16293) deny(1) iokit-open-service IOUSBHostInterface
Looking more closely at things, I think this could be a side effect of some additional hardening we added specifically around mass storage access. A few things to try:
-
Google Chrome has a user client attached to IOUSBHostDevice and, for testing purposes, I would recommend removing Chrome and ensuring the user client is gone (you can see it in the IORegistry). I don't think it's a direct factor here, but I've also seen many cases where time ended up being wasted because a side factor like this ended up distorting the testing process.
-
There's a side complication here about how your helper tool is launched and how it gets correct access. For the time being, I would ignore that issue entirely and do your testing directly with in a "standard" app (not a helper tool). Once it's sorted out in that context, then you can figure out how to get the helper working.
Focusing on the that standalone test app, try the following:
-
Add the NSRemovableVolumesUsageDescription to your test app and see if your user client access triggers the volume dialog and corrects the issue.
-
If the dialog doesn't trigger, try directly accessing a file on the volume while it's mounted (I would just hard code the path), then unmounting the volume and opening the client.
-
If the dialog doesn't trigger in #2 and/or the file access fails, then I would try using a open panel to select any object in the volume, then unmount and try opening the user client.
-
Give you app Full Disk Access (FDA) and try opening the user client.
Returning to your helper tool, getting it working will depend on which test above succeeds and exactly how your tool is launched. In the simplest case (#1 or #2), then it may be enough to just add NSRemovableVolumesUsageDescription to the main app and TCC allowing your helper tool to inherit. However, it's also possible that you'll need to put your helper tool into an app bundle so that it can include it's own NSRemovableVolumesUsageDescription.
Kevin Elliott
DTS Engineer, CoreOS/Hardware
