Your message dated Sat, 05 Aug 2023 23:31:11 +0200 with message-id <87v8dtch28....@frougon.crabdance.com> and subject line Re: doesn't apply MODE="0664" action to uinput upon boot anymore has caused the Debian Bug report #1042817, regarding doesn't apply MODE="0664" action to uinput upon boot anymore to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1042817: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042817 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: udev Version: 254-1 Severity: normal Dear maintainer, The computer this report is sent from runs sid and is upgraded almost daily. The problem described here appeared on the first boot of 2023-07-20 and is still present today. This computer has the following rule in /etc/udev/rules.d/90-local-uinput.rules (and no other rule in that file): SUBSYSTEM=="misc", KERNEL=="uinput", GROUP="a_user_group", MODE="0664" This has been working fine for years, until 2023-07-20. Now, after booting, one sees that the MODE="0664" action either hasn't been applied, or has been cancelled by something else: # ls -l /dev/uinput crw------- 1 root a_user_group 10, 223 Jul 30 11:04 /dev/uinput # (which causes failures in a program that relies on /dev/uinput being writable by a_user_group). If, after boot, I manually run as root: udevadm control --reload-rules && udevadm trigger' then the rule is properly applied: # ls -l /dev/uinput crw-rw-r-- 1 root a_user_group 10, 223 Jul 30 11:09 /dev/uinput # Many thanks in advance for your help. Regards Florent -- Package-specific info: -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-1-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages udev depends on: ii adduser 3.137 ii libacl1 2.3.1-3 ii libblkid1 2.39.1-3 ii libc6 2.37-6 ii libcap2 1:2.66-4 ii libkmod2 30+20230519-1 ii libselinux1 3.5-1 ii libudev1 254-1 ii systemd-dev 254-1 udev recommends no packages. udev suggests no packages. Versions of packages udev is related to: ii systemd 254-1 -- debconf information: udev/new_kernel_needed: false udev/title/upgrade: udev/sysfs_deprecated_incompatibility: udev/reboot_needed:
--- End Message ---
--- Begin Message ---Hi, AFAIUI: - nowadays, systemd-logind dynamically sets up ACLs to give device access to the logged-in user (and possibly revoke access when switching to a different session); - this is influenced by the 'uaccess' tag in udev. I replaced the aforementioned udev rule with: SUBSYSTEM=="misc", KERNEL=="uinput", TAG+="uaccess" which appears to solve my problem. Therefore, I am closing the bug. Feel free to reply if you think I'm doing this in a clumsy way; the above setup is for a Python script that injects mouse button press events using the UInput class of python3-evdev. Thanks for your attention. Regards -- Florent
--- End Message ---
