Date: Wed, 30 Mar 2016 10:30:35 +0100 From: Conor <interloper255@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: freebsd-usb@freebsd.org Subject: Re: libusb permission error (?) when attempting to detach device which is not attached Message-ID: <CALodZiBvs3LjF0%2BstADUHFnj5z%2BxZgBEtZLK78V_57nob5-PAQ@mail.gmail.com> In-Reply-To: <56FB7C64.5090801@selasky.org> References: <CALodZiBZaO7PoYn6dJmp%2BhgOGjgn6-QbwbazeBjyUyUPpWVM-A@mail.gmail.com> <56FB7C64.5090801@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you for your response. This clears up a few things. 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. > Duly noted. The privilege check failure is valid, then. To me, it doesn't seem to align with the devfs rules I mentioned, but I don't know the full scope of PRIV_DRIVER, so I may be way off. Regarding 'currently', is this likely to change in 11.0? > >> 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. > > Got it. This was my solution to the issue, however, it would still require superuser privileges to detach the device if an active driver is present, right? The remaining approach, as far as I can see, is to run openocd with elevated privileges, as opposed to avoid attempting to detach the device by checking for an active driver. Not optimal, but unavoidable, I think. -- Conor.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALodZiBvs3LjF0%2BstADUHFnj5z%2BxZgBEtZLK78V_57nob5-PAQ>