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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
