On Wed, 2 Apr 2014, Nestor Lopez Casado wrote: > >> If a user wants to configure/control the device there are two choices, > >> either write a hid-specific driver to deal with the vendor specific > >> collection, or open the corresponding /hidraw node from userspace. > >> > >> But a hidraw node that carries system input data requires root priviledges. > >> > >> I'm interested in hearing your opinions on how to add the capability > >> for a normal user process to control/configure a HID device via > >> reports exchanged with a vendor collection. > >> > >> I have one proposal, which is to create, say "/dev/hidvendorX", nodes > >> for all top level HID collections which are today ignored by hid-input > >> and/or other subsystems. > >> > >> These nodes would not require root priviledge by default and thus, > >> users could control/reconfigure their devices from a standard > >> application while keeping the "standard" input functionality intact. > > > > Why not write a kernel driver? We have a pretty nice infrastructure > > for all this. > > Do you mean a "hid-specific" driver for certain vid & pid devices ? I indeed believe that it's what David was proposing. Writing in-kernel drivers that handle just specific collections/usages, and let the rest be handled by the core infrastructure, is super-easy these days. Also, if you need users to be able to trigger particular actions being perfomed by the driver, sysfs knobs should be a reasonable way to doing this. As an example of such interface -- creating a sysfs trigger for hid-logitech-dj that will send the pairing command to the unified receiver, has been on my TODO list for quite some time already (and was even suggested by Linus). > > If it's a license-issue, I recommend using udev rules to change > > permissions on the requested devices directly during setup. You can > > then use hidraw. > It is not a license issue, it is a security issue. > > Every hid class interface, (either usb, bluetooth, i2c, etc) has an > associated hidraw node, and that node aggregates all reports sent from > the device. > > Say that for example, the device has a keyboard collection and a > vendor collection, then changing permissions on the associated hidraw > node (so as to give any desktop user unrestricted access to the vendor > collection) would open the door to malicious code that could log the > keyboard activity (as both the vendor reports and input reports are > seen on the same hidraw node) I think I am missing the point here. If you own the credentials of the session owner, you can log keystrokes anyway even now, just use xinput list xinput test <id> and see the result :) Admittedly, this is a little bit more difficult when you are outside X11 session, but I am not sure how much concerned you are about such scenario anyway. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
