USB reset fails when using a LimeSDR Mini on FreeBSD

[Hans Petter Selasky]

On 2020-07-02 11:15, Jan Behrens wrote:
> On Thu, 2 Jul 2020 10:54:27 +0200
> Hans Petter Selasky <hps at selasky.org> wrote:
> 
>> On 2020-07-02 10:47, Jan Behrens wrote:
>>> But wouldn't both drivers require access to the entries in /dev ?
>>
>> Yes, user-space drivers would require access to /dev, yes, but kernel
>> drivers not, like mouse, keyboard, storage, network.
>>
>>> Thus not every user could mess with any USB device, or do I get it
>>> wrong?
>>
>> A so-called composite USB device may appear like a USB storage device
>> (kernel driver) and a security token (firefox). Firefox can only grab
>> the device if you set the proper permissions for /dev of course, but the
>> reset device IOCTL then also becomes possible, which is why we currently
>> block it for non-root.
>>
>> --HPS
> 
> Okay, so if I understand it right, the problem is due to devices that
> shall be partly accessible by root, and partly by users. Some device
> nodes (e.g. /dev/usb/2.2.1 ) while others (e.g. /dev/usr/2.2.2 ) are
> limited to root access only. An USB reset always affects all devices
> (e.g. also /dev/usb/2.2.2, 2.2.3, etc.), right?

Yes, correct.

> Disregarding implementation complexity, I'd say that resetting a USB
> device should only be possible if a user has access to all sub-devices
> (or even better to a special device node that represents the device as
> a whole).

Maybe we can check if any kernel side drivers are attached at the time 
of reset device. It might be racy, because kernel drivers can be loaded 
and attached at any time. But it will work.

What do you think?

> 
> That sounds better than adding a sysctl option to me. But I assume that
> would require a lot of changes in the code?

If a simple rule can be formulated, I could implement it in the generic 
USB kernel code.

--HPS