On Mon, Apr 25, 2022 at 04:28:40PM +0200, Bastien Nocera wrote:
> On Mon, 2022-04-25 at 16:10 +0200, Greg Kroah-Hartman wrote:
> > On Mon, Apr 25, 2022 at 03:23:15PM +0200, Bastien Nocera wrote:
> > > There is a need for userspace applications to open USB devices
> > > directly,
> > > for all the USB devices without a kernel-level class driver, and
> > > implemented in user-space.
> > >
> > > End-user access is usually handled by the uaccess tag in systemd,
> > > shipping application-specific udev rules that implement this
> > > without too
> > > much care for sandboxed applications, or overall security, or just
> > > sudo.
> > >
> > > A better approach is what we already have for evdev devices: give
> > > the
> > > application a file descriptor and revoke it when it may no longer
> > > access
> > > that device.
> >
> > Who is going to use this "better" approach? Is there support in
> > libusb
> > for it? Who talks raw usbfs other than libusb these days?
>
> Did you read the follow-up mail with the links to example code for the
> hid revoke support?
HID revoke does not mess with usbfs though. Or if it does, I don't
understand the connection.
And usually the 0/X email has the context, not follow-on messages that I
didn't read yet :)
> > > This patch is the USB equivalent to the EVIOCREVOKE ioctl, see
> > > commit c7dc65737c9a607d3e6f8478659876074ad129b8 for full details.
> >
> > c7dc65737c9a ("Input: evdev - add EVIOCREVOKE ioctl") is how I
> > thought
> > we were supposed to write out commits in changelogs these days :)
> >
> > >
> > > Note that this variant needs to do a few things that the evdev
> > > revoke
> > > doesn't need to handle, particular:
> > > - cancelling pending async transfers
> > > - making sure to release claimed interfaces on revoke so they can
> > > be
> > > opened by another process/user, as USB interfaces require being
> > > exclusively claimed to be used.
> >
> > I love the idea of a real revoke() someday, but can't you just do the
> > "unbind/bind" hack instead if you really want to do this? Who wants
> > to
> > pass usbfs file descriptors around these days?
>
> Again, please read the follow-up mail where I talk of the BPF support
> patch that would allow revoking USB fds without relying on a service in
> the middle to access devices (although that's eventually going to be
> the way to do things to allow elevating access to devices).
So would bpf be working at the usbfs level here? I still don't
understand the connection...
thanks,
greg k-h
