2

Im experimenting with WebUS, or more precise, accessing a USB device through a web page written using DART (Angular DART).

After fiddling around for a bit, I got the basic concept working using Chrome V63 on a Windows 10 Desktop PC. It allows me to send and receive data to a USB endpoint. So far so good :-)

However, when trying the same URL on a (Samsung 500C) Chromebook, running Chrome version 63, the problem arises when USBdevice.open() is called, I get an "Uncaught DOMException: Access denied" exception.

In the debugger, looking at the USBdevice properties, opened: false and Interface claimed: false indicating no other is using the USB adapter.

Looking some more, Chrome://system under device_event_log it shows an USB EVENT: usb_device_linux.cc:99 Permission broker failed to open the device: org.freedesktop.DBus.Error.Failed: permission_broker/permission_denied:Permission to open '/dev/bus/001/032' denied (2)

Any suggestions are welcome.

Bas E
  • 96
  • 1
  • 7

1 Answers1

0

The Chrome OS permission_broker applies access control rules to USB devices that may not apply on other platforms. The purpose of these rules is to prevent a Chrome App (using the chrome.usb API) or a website (using the WebUSB API) from accessing a USB device that is important to the system.

The rules the passed or failed when checking whether a device access request will be allowed are logged to the system log which is available in the "syslog" section of chrome://system on a Chrome OS device. Search that for lines containing the string "permission_broker" and you will see a section like this:

2018-02-04T20:27:31.845733-05:00 INFO permission_broker[1249]: ProcessPath(/dev/bus/usb/001/003)
2018-02-04T20:27:31.883050-05:00 INFO permission_broker[1249]:   AllowUsbDeviceRule: ALLOW
2018-02-04T20:27:31.883058-05:00 INFO permission_broker[1249]:   AllowTtyDeviceRule: IGNORE
2018-02-04T20:27:31.918667-05:00 INFO permission_broker[1249]:   DenyClaimedUsbDeviceRule: IGNORE
2018-02-04T20:27:31.918722-05:00 INFO permission_broker[1249]:   DenyUninitializedDeviceRule: IGNORE
2018-02-04T20:27:31.918758-05:00 INFO permission_broker[1249]:   DenyUsbDeviceClassRule: IGNORE
2018-02-04T20:27:31.918765-05:00 INFO permission_broker[1249]:   DenyUsbDeviceClassRule: IGNORE
2018-02-04T20:27:31.918789-05:00 INFO permission_broker[1249]:   DenyUsbVendorIdRule: IGNORE
2018-02-04T20:27:31.918794-05:00 INFO permission_broker[1249]:   AllowHidrawDeviceRule: IGNORE
2018-02-04T20:27:31.918799-05:00 INFO permission_broker[1249]:   AllowGroupTtyDeviceRule: IGNORE
2018-02-04T20:27:31.918804-05:00 INFO permission_broker[1249]:   DenyGroupTtyDeviceRule: IGNORE
2018-02-04T20:27:31.918814-05:00 INFO permission_broker[1249]: message repeated 2 times: [   DenyGroupTtyDeviceRule: IGNORE]
2018-02-04T20:27:31.918819-05:00 INFO permission_broker[1249]:   DenyClaimedHidrawDeviceRule: IGNORE
2018-02-04T20:27:31.918824-05:00 INFO permission_broker[1249]:   DenyUnsafeHidrawDeviceRule: IGNORE
2018-02-04T20:27:31.918830-05:00 INFO permission_broker[1249]: Verdict for /dev/bus/usb/001/003: ALLOW

You are most likely to find that it is DenyClaimedUsbDeviceRule which is blocking the device. This means that there is already a Linux kernel driver which has attached itself to the device.

Reilly Grant
  • 5,590
  • 1
  • 13
  • 23
  • The issue i faced was due that the original USB adaptor used USBHID and the OS claimed the USB adapter. Implementing WebUSB solved my issue as it didn't get claimed by the OS. The current implementation using WebUSB, works great under windows, a Chromebook, and MacOS (did not try Linux). – Bas E Feb 21 '18 at 00:47