Cloning devices does not work on several operating systems
riastradh opened this issue · 4 comments
On NetBSD, OpenBSD, probably FreeBSD, and I would guess most Unix systems, each device node for a HID can only be opened once at a time; subsequent attempts fail with EBUSY until the device is closed, so that separate programs can't just stomp over each other's input and output streams. So the clone_device_as_write_only implementations on these systems which just reopen the same device path have never worked.
The symptom is that examples/ctap2.rs goes into a loop trying and failing to open any FIDO device, with cryptic log messages like this:
[2023-04-20T21:09:52Z WARN authenticator::statemachine] error while cloning device: "/dev/uhid0"
[2023-04-20T21:09:52Z DEBUG authenticator::transport::device_selector] Device not a token event: "/dev/uhid0"
I tried the attached clone.patch to make clone_device_as_write_only to dup the existing file descriptor -- this just gives a new descriptor number to refer to the same open state, in the hope that that's enough for authenticator-rs's purposes, although I got lost in the abstractions trying to figure out what these purposes are. This seems to make more progress and identifies the device, but then crashes in a panic about UnsupportedOption (ctap2.log).
I tried using the main and ctap1 examples, but they're not there any more. Is there a reduced test case that can just exercise the old reliable U2F protocol and none of the fragile bells and whistles of CTAP2 to make progress on this separately from fixing whatever is wrong with CTAP2?
Let me know if this works for you: #253. Just check out that branch and pass --fallback to the ctap2 example.
Thanks! Sorry for the grumpy and incompletely diagnosed bug report, had just spent several hours fighting with Firefox and cargo to diagnose why webauthn stopped working in an update and fixing it.
On your branch:
- With the
--fallbackargument, the ctap2.rs example works now, with or without my clone.patch. So I assume the U2F fallback suppresses any use of the clone_device_as_write_only operation. - Without the
--fallbackargument, the ctap2.rs example continues to fail in two different ways -- cloning error without my clone.patch, UnsupportedOption panic with my clone.patch.
So I guess I'll open a separate issue for the UnsupportedOption panic and leave this one to track whether cloning actually requires a separate open, could be done with dup instead, or is broken either way.
@riastradh Could you try the patch in #260?