Hello,
This is a code-signing / entitlement-process question. The USB API details are included
only to explain why the entitlement is required.
We maintain a macOS VDI client distributed with Developer ID (outside the Mac App Store,
notarized). USB redirection uses SPICE usbredir over libusb 1.0.30.
To redirect USB mass-storage devices and printers, the macOS kernel drivers must be detached before the device can be claimed. libusb does this in
darwin_detach_kernel_driver_locked(): it calls IOServiceAuthorize() and then
USBDeviceReEnumerate() with kUSBReEnumerateCaptureDeviceBit. The public IOUSBLib.h
header documents that this requires either:
1. the com.apple.vm.device-access entitlement plus a successful IOServiceAuthorize(), or
2. root privileges.
Running the whole VDI client as root is not acceptable, so we need the entitlement on a
Developer ID build. Without it, libusb returns LIBUSB_ERROR_ACCESS when detaching the
kernel driver for these devices, which is the only blocker for the feature.
In Certificates, Identifiers & Profiles -> Identifiers -> App ID -> Capabilities, the only
USB-related entries we see are "Claim USB Accessory"
(com.apple.developer.accessory-access.usb) and "DriverKit USB Transport (development)".
com.apple.vm.device-access is not listed, and we could not find a request form for it.
Could DTS or the entitlements team clarify:
- Is com.apple.vm.device-access still granted to Developer ID apps? What is the correct
request channel (capability request, entitlement request form, TSI, or a Developer ID
provisioning profile)? - On macOS 27+, is Accessory Access + Claim USB Accessory the supported replacement for
IOUSBFamily device capture? Does it expose raw USB transfers suitable for forwarding a
device to a remote guest OS over a protocol such as usbredir, or is it limited to local
Virtualization.framework VMs? - If com.apple.vm.device-access is not available for this use case, is a DriverKit USB
transport extension the recommended architecture for a libusb-based redirection client?
Any guidance on the correct request process would be appreciated. We can provide the
bundle ID, Team ID, target macOS versions, device classes, and user-consent/security
design privately if needed.
Thanks,
liyucai
For context, I administer the process for requesting the com.apple.vm.device-access entitlement but I don’t set the actual policy or make the final approvals.
com.apple.vm.device-access is intended to be used by virtual machine apps [1] that ship in the Mac App Store, where escalating privileges is not an option.
Historically our recommendation to folks in your situation, where you’re shipping outside of the Mac App Store, was to factor the USB bits of your app out into a privileged helper and have your app use that access the accessory.
Nowadays our advice is to start with Accessory Access framework. If that works for you then you only need the privileged helper if you support older versions of macOS. OTOH, if Accessory Access doesn’t cut the mustard then a) you should file a bug about the problems you hit, and b) you can continue to achieve your goal using a privileged helper.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] I’ve seen cases where the entitlements has been granted to remote access apps, specifically, apps that allow access to remote virtual machines.