How to make udev not assign seat to bluetooth keyboard
5
votes
0
answers
901
views
I would like to use a bluetooth keyboard as a remote control (PIN entry pad for opening an electric strike) instead of as an actual keyboard for console input. I can get access to the bluetooth keyboard just fine using the following udev rule:
ENV{ID_BUS}=="bluetooth", ATTRS{phys}=="00:1a:7d:e3:76:60", ENV{ID_INPUT_KEYBOARD}=="?*", GROUP="uucp", SYMLINK+="btremote"
This puts the device node in the
uucp
group (which is the group that needs access to the key events), and also creates a symbolic link from /dev/btremote
to /dev/input12
or whichever is the appropriate device (since the number seems to vary). So far so good.
Unfortunately, the keyboard and a built-in pointing device _also_ get attached to to my X session, and show up when I run loginctl seat-status seat0
. This is annoying and dangerous, because I plan to leave the remote in a less secure location than my console and definitely don't want people typing at my console (or using the pointing device also built into this keyboard).
I've tried a number of variations of:
ATTRS{phys}=="00:1a:7d:e3:76:60", TAG-="seat", ENV{ID_AUTOSEAT}=""
to try to exclude the device from getting attached to my X session, but nothing works with udev. As a workaround, I know I can create a bogus seat and loginctl attach
the keyboard to seat1
, but since this is a security issue, I'd rather have a simple udev rule that completely excludes any bluetooth device matching that MAC address as something untrusted that nothing automatic can happen to.
My question is how this seat assignment mechanism works and how I can securely exclude a set of devices from consideration (a set because the keyboard actually shows up as 4 input devices). In case it's relevant, I'm using arch linux with systemd-242.32.
**update** I'm adding the rules to a file called /etc/udev/rules.d/72-btremote.rules
, so that it runs between /usr/lib/udev/rules.d/71-seat.rules
and /usr/lib/udev/rules.d/73-seat-late.rules
. The former seems to be where the seat
tag gets added, while the latter seems to assign the seat number, but I admittedly do not understand how this works.
**update 2** After a bunch more playing around, I was able to get what I wanted with
ATTRS{phys}=="00:1a:7d:e3:76:60", ENV{ID_SEAT}="none"
This still feels ugly because I think it's creating a seat called "none" instead of disabling the seat tag (or at least would be if any other device had the master-of-seat
tag). I still don't understand what's going on or why TAG-="seat"
didn't work, so am still leaving this question unanswered in the hopes that someone else can explain.
Asked by user3188445
(5539 rep)
Jul 20, 2019, 10:56 PM
Last activity: Jul 21, 2019, 04:50 AM
Last activity: Jul 21, 2019, 04:50 AM