On 2020-07-02 11:15, Jan Behrens wrote:
On Thu, 2 Jul 2020 10:54:27 +0200
Hans Petter Selasky <h...@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
_______________________________________________
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"
