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
_______________________________________________
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
