[systemd-devel] WebUSB

[Lars Knudsen]

On Fri, Jan 20, 2017 at 12:05 PM, Greg KH <gregkh at linuxfoundation.org>
wrote:

> On Fri, Jan 20, 2017 at 11:43:24AM +0100, Lars Knudsen wrote:
> >
> >
> > On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie <
> simon.mcvittie at collabora.co.uk
> > > wrote:
> >
> >     On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> >     > 2. make sure that webusb devices will be somehow accessible to be
> used by
> >     a
> >     > browser running with user permissions (current temp solution
> listed here:
> >     > adding user to plugdev, adding 0664 permissions to device: https://
> >     > developers.google.com/web/updates/2016/03/access-usb-
> devices-on-the-web )
> >
> >     > (udev/systemd task).
> >
> >     Since I didn't see a response to this: this sounds like a job for
> uaccess.
> >     Most things that happened via the plugdev group (on
> Debian/derivatives)
> >     5 or 10 years ago should happen via uaccess now.
> >
> >     TAG+="uaccess" in a udev rule results in an ACL being set so that
> >     a currently-active logind session on the same seat can read and write
> >     the device node.
> >
> >
> > OK thanks!
> >
> >  - so if we can make a rule that consistently detects USB devices with a
> WebUSB
> > interface defined, we should get this in as a standard rule.
>
> Sure, feel free to write the helper binary that will do this.
>
Cool, I am still wondering if we could do it with a script.  Do you have an
example of a binary for udev?
(I am assuming it's a source for a plugin to be shipped with and callable
by udev?)


>
> > Is it possible to give access on an interface level - or would it always
> have
> > to be the full device?
>
> How would you provide userspace access to only one USB interface on
> Linux?
>
The full device should be fine if it has a WebUSB interface (even in a
composite scenario)

br
Lars

>
> thanks,
>
> greg k-h
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170120/c384f644/attachment.html>