It also means it depends on installing the same fastboot udev rules as usual on Linux which annoys me. I had to add that back to grapheneos.org/install/web since I'd deleted it when I copied the CLI installation guide there expecting that it wasn't going to be needed.
Conversation
it would be *much* more concerning if it had a SUID binary that can talk to udev.
1
Yeah, but originally I expected that WebUSB was a special thing that would use a generic WebUSB driver. I didn't realize it was just normal USB.
2
1
For common USB devices, the udev rules already exist. It's actually quite annoying that it's not more generic. I don't really understand the point of someone having to maintain github.com/M0Rf30/android in order to authorize local users (users physically at a session) to use it.
1
1
The only reason the Debian package with the udev rules works for current Pixels despite being so out-of-date is that they've kept using the same ids from Nexus devices:
github.com/M0Rf30/android
It wouldn't work well for most other brands of devices.
1
2
Needing to teach people to put a file in /etc/udev/rules.d/ is a pretty bad usability issue. It really doesn't make any sense. Needing to authorize a sandboxed app to use a device actually makes sense. The user themselves should be able to use local USB devices... sigh.
1
4
are there any USB devices that would be unwise to expose to anyone in `plugdev`?
2
I don't really think it ever makes sense to disallow a user at a physical session from accessing USB devices. Disallowing apps from doing it without authorization actually makes sense but it's not what they're doing.
2
TAG+="uaccess" makes it so that if you're at a local session, you can use the device. The adbusers group in these udev rules is useless for most people. It's useful if you need it to work via a non-local session (SSH).
1
1
That design actually makes sense, but I don't see why uaccess is handled with a hard-wired rule for every kind of device. It seems like that's just how USB devices should work on desktop Linux normally. I don't get it. This whole file of hard-wired ids makes me really sad...
1
2
The purpose of systemd-logind (previously consolekit) is largely to deal with tracking remote vs. physical sessions and the active session to grant/revoke these kinds of privileges. And yet... I need to deal with it myself by opening some file as root in vim to use USB in 2020.
i mostly noticed it when it broke policykit in a way that was so unpleasant to debug that i eventually just rebuilt it with a local patch disabling access control -____-
2