tumbleweed setfacl on sddm login mystery
I noticed on my existing tumbleweed desktop, when I login a setfacl appears to be setting permissions on /dev/i2c-1 and they are reassigned to sddm on logout. % getfacl /dev/i2c-1 getfacl: Removing leading '/' from absolute path names # file: dev/i2c-1 # owner: root # group: root user::rw- user:michael:rw- group::--- mask::rw- other::--- This appears to happen for all users. But on a recently installed tumbleweed I don't see this behavior - no users have access to the i2c devices, no ACL's are assign on login. There is no i2c related group on either the old or new machine. Both machines are on the latest tumbleweed, both run Nvidia's driver. So I would expect the same behaviour on both. I do see that the nvidia devices have ACL's set on login (so perhaps this is X11 or nvidia related): getfacl /dev/nvidia0 getfacl: Removing leading '/' from absolute path names # file: dev/nvidia0 # owner: root # group: video user::rw- user:michael:rw- group::rw- mask::rw- other::--- It's possible I setup something years ago and have forgotten about it. I think I have used i2c in the past for sensors. More recently I've started using it with ddcutil and vdu_controls (which I wrote) - I was puzzled that they work with no permission changes required on my desktop, but not on this new machine. I'm looking for clues that might throw some light on the situation. Michael
W dniu 28.08.2022 o 03:29, Michael Hamilton pisze:
I noticed on my existing tumbleweed desktop, when I login a setfacl appears to be setting permissions on /dev/i2c-1 and they are reassigned to sddm on logout.
% getfacl /dev/i2c-1 getfacl: Removing leading '/' from absolute path names # file: dev/i2c-1 # owner: root # group: root user::rw- user:michael:rw- group::--- mask::rw- other::---
This appears to happen for all users. But on a recently installed tumbleweed I don't see this behavior - no users have access to the i2c devices, no ACL's are assign on login. There is no i2c related group on either the old or new machine.
Both machines are on the latest tumbleweed, both run Nvidia's driver. So I would expect the same behaviour on both. I do see that the nvidia devices have ACL's set on login (so perhaps this is X11 or nvidia related):
getfacl /dev/nvidia0 getfacl: Removing leading '/' from absolute path names # file: dev/nvidia0 # owner: root # group: video user::rw- user:michael:rw- group::rw- mask::rw- other::---
It's possible I setup something years ago and have forgotten about it. I think I have used i2c in the past for sensors. More recently I've started using it with ddcutil and vdu_controls (which I wrote) - I was puzzled that they work with no permission changes required on my desktop, but not on this new machine.
I'm looking for clues that might throw some light on the situation.
Michael
Search for "uaccess" in /lib/udev/rules.d/ and /etc/udev/rules.d/
On Sunday 28 August 2022, Adam Mizerski wrote:
W dniu 28.08.2022 o 03:29, Michael Hamilton pisze:
I noticed on my existing tumbleweed desktop, when I login a setfacl appears to be setting permissions on /dev/i2c-1 and they are reassigned to sddm on logout.
...
I'm looking for clues that might throw some light on the situation.
Michael
Search for "uaccess" in /lib/udev/rules.d/ and /etc/udev/rules.d/
Very good clue. Thanks. # find /lib/udev/rules.d/ /etc/udev/rules.d/ -type f | xargs grep uaccess | grep i2 /lib/udev/rules.d/60-openrgb.rules:KERNEL=="i2c-[0-99]*", TAG+="uaccess" The older machine had the OpenRGB package installed. Not sure why: # zypper se -i --requires OpenRGB-0.7-2.6.x86_64 did not give any results. It could be because of Roccat mouse software that I have long since removed (after the Roccat mouse expired). Or maybe because my current motherboard has RGB lighting and I was once thinking of having a play (and since have forgotten about it). I installed the same package on the newer machine, and that resulted in both machines having the same permissions. Perhaps I should suggest a similar rule to the owner of the ddcutil package. It seems a better solution than setting up a i2cdev group. Thanks again, Michael
participants (2)
-
Adam Mizerski -
Michael Hamilton