On Tue, Apr 15, 2014 at 9:39 AM, Jiri Kosina <jkosina@xxxxxxx> wrote: > On Mon, 14 Apr 2014, Nestor Lopez Casado wrote: > >> After considering our discussion here, which is your position on >> extending the hidraw nodes to include separate nodes for top level >> vendor collections ? > > The exact usecase is still a bit unclear to me. Has there been any > explanation how you are going to deal with the fact that X protocol > exposes all the events to X session owner anyway? (sorry if it was and I > missed it). The X session owner can spy its own keystrokes. This seems acceptable. Hidraw nodes are the only way a user can talk "vendor hid" with plugged devices. Once you are less restrictive with hidraw nodes (i.e. grant access to more users that root) to allow hid vendor interaction, then any of those users can log anything happening on the concerned hidraw node, even remotely. This is not the case in X. Having more granularity at the hidraw level enables assigning different user rights to the different nodes belonging to the same parent hid device, so that sensitive user input can remain protected while access to the vendor interface can be left open. As David said, this clearly does not solve "all problems", as some vendor features in some devices might not be safe to be exposed, but then it will be up to the users/vendors to grant/block access to those collections via udev rules. Moreover, this feature will keep a very similar interface to current hidraw ioctl/open/close and the code will most likely remained contained to a single module or even can simply become part of hidraw.c As David mentions, the same kind of functionality could also be achieved via hid specific drivers for vendor collections in each of the products, but it has the drawback that we will be proliferating more hid-specific drivers whose only purpose will be to expose a vendor interface to user applications, creating the potential for kernel code duplication and disparate user interfaces. > > Frankly, I'd really like to avoid any parsing (deciding about collections) > whatsoever around hidraw, as that was the whole point of creating it in > parallel to hiddev was simply 'no parsing, raw access'. We should avoid naming the new nodes "hidrawX" they could be "hidvendorX" for instance, or it could also be "hidcolX" where col stands for collection. We will be moving the "raw" one level down. It can be thought of as a multiple interface usb device that already creates multiple hidraw devices, but taken one step further. > > Thanks, > > -- > Jiri Kosina > SUSE Labs Cheers, -nestor -- 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
