On 03/29/16 22:05, Conor wrote:

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

         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?


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.


freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to