I’m gonna leave this here if another Linux user runs into this issue.
So let’s say you have an RFID reader that acts as a keyboard wedge (USB or BT) - the KBR1 for instance - and you have a custom program that reads the corresponding input device file directly in exclusive mode, so the keyboard events are processed by your program only and don’t get sent to the console.
As long as your program is running, it’s safe: if you scan your implant while you’re chatting in IRC, it won’t dump the UID in the channel for all the other users to see. But then you have two problems:
-
Which of the
/dev/input/event*
files should your program open? The exact event file that gets assigned to the keyboard wedge isn’t fixed and is liable to change at each connection. USB devices are often listed in/dev/input/by-id/
nominatively but not always, and BT keyboards never are. -
When your program isn’t running and keeping the event device open in exclusive mode, by default, the keyboard events revert to being sent to the console. Not safe…
Here’s the solution: Add this file in /etc/udev/rules
- for example, name it /etc/udev/rules/99-kbd_wedge.rules
:
SUBSYSTEMS=="input", ATTRS{name}=="name_of_your_device", SYMLINK+="input/kbd_wedge", ENV{ID_SEAT}="none"`
Then reload and rerun the udev rules as root:
# udevadm control --reload-rules
# udevadm trigger
What this does is, it symlinks the particular event device file assigned to the device to /dev/input/kbd_wedge
and assigns it the bogus seat ID “none”, so that it doesn’t get picked up by the standard console input stack (which is “seat0” by default).
You can find out the exact name of your device using the evtest
utility.