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?

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?

I appreciate any insights or input you might have.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to