システムをアップデートしたらなぜか/dev/uinputの権限が不足してxkeysnailが動かなくなったので対策を調べました。~~原因がよくわからないので対処療法ですが。。~~

[2023/12/21追記] これはsystemd 254.1のバグだった模様（参考）。現在の255.1-1-archでは下記の変な挙動は起きませんので、安心して660を指定ください（なお、「対処」の設定でも問題は起きないのでどっちでも良い）。

環境

Arch linux (6.4.7-arch1-3)
Systemd 254 (254-1-arch)

現象

udevのルールで指定した/dev/uinputのパーミッションが指定通りにならない¹ ²。660の二桁目はどこへ・・・？

uinput.rules (old)

SUBSYSTEM=="misc", KERNEL=="uinput", MODE="660", GROUP="input"

$ ls -l /dev/uinput

crw------- 1 root input 10, 223  8月  6 11:55 /dev/uinput

対処

uinput.rulesを以下のように変更する。

uinput.rules (new)

SUBSYSTEM=="misc", KERNEL=="uinput", TAG+="uaccess"

これにより/dev/uinputにuaccessタグが設定され、一般ユーザからの読み書きが可能になります（下記、動作の参考になりました）。

以下のように、ACLでユーザclarryからの読み書き権限が付与されていますね。

$ ls -l /dev/uinput

crw-rw----+ 1 root root 10, 223  8月  6 12:08 /dev/uinput

$ getfacl /dev/uinput

getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: root
user::rw-
user:clarry:rw-
group::---
mask::rw-
other::---

…特定のパーミッションを指定できるようになったわけではないのでちょっと気持ち悪いですね。またハマったら追記します。

なお、/etc/modules-load.d/uinput.confにuinputは記入してあります: github.com。 ↩
ブートログを見る限りuinputモジュールの読み込み→udevの起動→ルールの適用の順になるが、これをudev起動→modprobe uinputの順にすると、何故か想定通り設定される？？ ↩