Hi,
I'd like to add a use case and a security argument for this bug.
Setup: Debian 13.7 (trixie), brightnessctl 0.5.1-3.1, brightness-udev
0.5.1-3.1, systemd 257.13-1~deb13u1, the niri Wayland compositor on a
MacBook Air. niri has no power daemon, so the brightness keys are bound
to brightnessctl.
Changing the screen backlight works, because my user is in the video
group. Changing the keyboard backlight fails:
$ brightnessctl -d smc::kbd_backlight set 255
Can't modify brightness: Permission denied
The udev rule shipped in brightness-udev grants write access to LED
devices only to the input group:
ACTION=="add", SUBSYSTEM=="leds", RUN+="bright-helper input g+w
/sys/class/leds/%k/brightness"
and the upstream README says this method "requires your user to be in
the video and input groups".
The input group also owns the raw input devices, including the keyboard:
crw-rw---- 1 root input 13, 68 /dev/input/event4 (Apple Internal
Keyboard / Trackpad)
and per Documentation/input/input.rst, evdev "passes the events
generated in the kernel straight to the program, with timestamps". So
with the current package, controlling a keyboard backlight through
brightnessctl means joining a group that lets every process running as
that user read all keystrokes, which undercuts Wayland's input
isolation.
systemd-logind already allows the active session to set LED brightness
without any group membership. This works for my user, which is not in
the input group:
busctl call org.freedesktop.login1 /org/freedesktop/login1/session/auto \
org.freedesktop.login1.Session SetBrightness ssu leds
smc::kbd_backlight 128
Building brightnessctl with ENABLE_SYSTEMD=1 would let it use this API,
so neither the input group nor brightness-udev would be needed on
systemd systems.
Cheers
Xau
