libusb permission error (?) when attempting to detach device which is not attached

[Hans Petter Selasky]

On 03/29/16 22:05, Conor wrote:
> Greetings,
>
> I'm unsure if this is the correct place for this discussion; if it is more
> suitably discussed elsewhere, please let me know.
>
> Currently, I'm looking into an issue with a port (devel/openocd), whereby
> attempting to detach a USB device fails due to, from what I can tell, a
> permissions error. First, some background;
>
> The port's pkg-message suggests adding the following lines to
> /etc/devfs.rules:
>
> =====
>   [localrules=10]
>          add path 'ugen*' mode 0660 group operator
>          add path 'usb/*'  mode 0660 group operator
>          add path 'usb' mode 0770 group operator
> ======
>
> ...such that members of the operator group may access attached hardware.
> I've done so, and my user is a member of the operator group. The device in
> question is an Olimex JTAG debugger, and I'm running 10.2-RELEASE.
>
> When starting OpenOCD as my user, it bombs out stating that
> libusb_detach_kernel_driver() has failed with LIBUSB_ERROR_OTHER. When
> starting as root, there is no error, and I can socat/telnet to the OpenOCD
> server and flash/debug a target.
>
> Initially, it seemed that it was, indeed, a permissions issue:
>
> 1) Some initial investigation of the FreeBSD libusb implementation, and
> kernel source, pointed at the failure being in privilege checking in the
> ioctl handler for USB_IFACE_DRIVER_DETACH whereby a check for PRIV_DRIVER
> fails (sys/dev/usb/usb_generic.c:2210) when running as my user. Naturally,
> the check for su returns success when running as root.
>
> 1a) Given the permissions alluded to in /etc/devfs.rules above, should this
> privilege check fail, given that the device node is one of ugenX.Y?

Hi,

Currently only root/superuser can alter the enumeration state of USB, 
like attaching/detaching kernel drivers. That's why there is a 
PRIV_DRIVER check in the IOCTL of USB_IFACE_DRIVER_DETACH.

>
> 2) I've patched the OpenOCD source to first check for an active driver with
> libusb_kernel_driver_active(), and only on success, attempting to detach
> the device. Whilst this rectifies the issue -- there is no active driver,
> ergo, no detach attempt is made and I can use the server as described with
> su, above -- is it reasonable/necessary to do this?

Unlike Linux, interface drivers can co-exist in userspace and the kernel 
for the same USB device, given they are not in use at the same time. 
Currently this and other user-space drivers should call 
libusb_kernel_driver_active(), but don't bail out if 
libusb_kernel_driver_active() does not succeed.

--HPS