TW - i2c permissions for normal users?
My i2c devices /dev/i2c-* are all set to 0660, yet non-root users logged into the desktop appear to have access. How is this achieved? Background: During a covid-19 lockdown I wrote vdu_controls, a GUI front end to ddcutil that I use to adjust the backlights on my external monitors: Ddcutil uses VESA DDC/MCCS over i2c to interact with external monitors. Details here: https://forums.opensuse.org/showthread.php/559401-Desktop-control-of-externa... https://www.ddcutil.com/ I recently had an enquiry from someone attempting to use vdu_controls on a non-SUSE distro. Clearly their problem is lack of permissions to /dev/i2c-* On other distributions the permissions seem to be granted by an entry in /etc/udev/rules.d such as KERNEL=="i2c-[0-9]*", MODE="0666" ( https://www.ddcutil.com/i2c_permissions/ ). I can't find where anything similar is set in Tumbleweed. But ddcutil is working fine, so how it a normal user getting access to /dev/i2c-*? I suspect it's due to an apparmor rule, but I can't find it. Puzzled.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2021-09-18 a las 10:27 +1200, Michael Hamilton escribió:
My i2c devices /dev/i2c-* are all set to 0660, yet non-root users logged into the desktop appear to have access. How is this achieved?
ACLs? - -- Cheers Carlos E. R. (from openSUSE 15.2 (Legolas)) -----BEGIN PGP SIGNATURE----- iHIEARECADIWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYUUXnBQccm9iaW4ubGlz dGFzQGdteC5lcwAKCRC1MxgcbY1H1bvKAJ464fQJ76eaxHV5ZCVSNSEucelPpwCf WMDYX6iqC2tZjvhB+beFaOLOd3Y= =JFNG -----END PGP SIGNATURE-----
On Saturday 18 September 2021, Carlos E. R. wrote:
El 2021-09-18 a las 10:27 +1200, Michael Hamilton escribió:
My i2c devices /dev/i2c-* are all set to 0660, yet non-root users logged into the desktop appear to have access. How is this achieved?
ACLs?
Thanks. Yes, that looks to be the case: 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::--- Wow, I'd never really noticed ACL's being used before (brings back memories of DEC's VMS). What's setting up the ACL's? I presume it's part of desktop login. Fascinating stuff.
On 18/09/2021 00.55, Michael Hamilton wrote:
On Saturday 18 September 2021, Carlos E. R. wrote:
El 2021-09-18 a las 10:27 +1200, Michael Hamilton escribió:
My i2c devices /dev/i2c-* are all set to 0660, yet non-root users logged into the desktop appear to have access. How is this achieved? ACLs?
Thanks. Yes, that looks to be the case:
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::---
Wow, I'd never really noticed ACL's being used before (brings back memories of DEC's VMS). What's setting up the ACL's? I presume it's part of desktop login. Fascinating stuff.
The same trick is used to give access to USB sticks you plug or to the audio devices. It is handled by what /I/ call the login manager, but the official name is display manager. cer@minas-tirith:~> l /dev/audio crw-rw----+ 1 root audio 14, 4 Sep 15 14:49 /dev/audio ----------^ The '+' symbol indicates there are ACLs. cer@minas-tirith:~> getfacl /dev/audio getfacl: Removing leading '/' from absolute path names # file: dev/audio # owner: root # group: audio user::rw- user:cer:rw- group::rw- mask::rw- other::--- cer@minas-tirith:~> -- Saludos/Cheers Carlos E. R.
On Saturday 18 September 2021, Carlos E.R. wrote:
On 18/09/2021 00.55, Michael Hamilton wrote:
On Saturday 18 September 2021, Carlos E. R. wrote:
El 2021-09-18 a las 10:27 +1200, Michael Hamilton escribió:
My i2c devices /dev/i2c-* are all set to 0660, yet non-root users logged into the desktop appear to have access. How is this achieved? ACLs?
Thanks. Yes, that looks to be the case:
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::---
Wow, I'd never really noticed ACL's being used before (brings back memories of DEC's VMS). What's setting up the ACL's? I presume it's part of desktop login. Fascinating stuff.
The same trick is used to give access to USB sticks you plug or to the audio devices. It is handled by what /I/ call the login manager, but the official name is display manager.
cer@minas-tirith:~> l /dev/audio crw-rw----+ 1 root audio 14, 4 Sep 15 14:49 /dev/audio
----------^ The '+' symbol indicates there are ACLs.
cer@minas-tirith:~> getfacl /dev/audio getfacl: Removing leading '/' from absolute path names # file: dev/audio # owner: root # group: audio user::rw- user:cer:rw- group::rw- mask::rw- other::---
cer@minas-tirith:~>
To refine my query to specifics: Where is the list of acl's set by the defined? How would the list be amended? Can I audit the list in my running system? A source of documentation would be fine, I don't mind a good read. I have tried searching the whole of / and /usr for any file containing i2c-[0-9]. No luck, but still curious.
On 2021-09-17 21:07:46 Michael Hamilton wrote:
|On Saturday 18 September 2021, Carlos E.R. wrote: |> On 18/09/2021 00.55, Michael Hamilton wrote: |> > On Saturday 18 September 2021, Carlos E. R. wrote: |> >> El 2021-09-18 a las 10:27 +1200, Michael Hamilton escribió: |> >>> My i2c devices /dev/i2c-* are all set to 0660, yet non-root users |> >>> logged into the desktop appear to have access. How is this |> >>> achieved? |> >> |> >> ACLs? |> > |> > Thanks. Yes, that looks to be the case: |> > |> > 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::--- |> > |> > Wow, I'd never really noticed ACL's being used before (brings back |> > memories of DEC's VMS). What's setting up the ACL's? I presume it's |> > part of desktop login. Fascinating stuff. |> |> The same trick is used to give access to USB sticks you plug or to the |> audio devices. It is handled by what /I/ call the login manager, but the |> official name is display manager. |> |> cer@minas-tirith:~> l /dev/audio |> crw-rw----+ 1 root audio 14, 4 Sep 15 14:49 /dev/audio |> |> ----------^ The '+' symbol indicates there are ACLs. |> |> cer@minas-tirith:~> getfacl /dev/audio |> getfacl: Removing leading '/' from absolute path names |> # file: dev/audio |> # owner: root |> # group: audio |> user::rw- |> user:cer:rw- |> group::rw- |> mask::rw- |> other::--- |> |> cer@minas-tirith:~> | |To refine my query to specifics: | |Where is the list of acl's set by the defined? How would the list be |amended? Can I audit the list in my running system? | |A source of documentation would be fine, I don't mind a good read. | |I have tried searching the whole of / and /usr for any file containing |i2c-[0-9]. No luck, but still curious.
I don't know where they would be defined for /dev/i2c*, but you can change them with the setfacl command. Leslie -- Distribution: openSUSE Leap 15.3 x86_64
On 18/09/2021 06.21, J Leslie Turriff wrote:
On 2021-09-17 21:07:46 Michael Hamilton wrote:
|On Saturday 18 September 2021, Carlos E.R. wrote:
...
|To refine my query to specifics: | |Where is the list of acl's set by the defined? How would the list be |amended? Can I audit the list in my running system? | |A source of documentation would be fine, I don't mind a good read. | |I have tried searching the whole of / and /usr for any file containing |i2c-[0-9]. No luck, but still curious.
I don't know where they would be defined for /dev/i2c*, but you can change them with the setfacl command.
Not in this case, they are dynamic. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On 18.09.2021 05:07, Michael Hamilton wrote:
To refine my query to specifics:
Where is the list of acl's set by the defined? How would the list be amended? Can I audit the list in my running system?
ACLs are applied by systemd-logind to all device nodes that have uaccess tag. Tags are assigned by udev rules. Look at udevadm info --export-db and search for :uaccess:. You can see rules with grep -rw uaccess /etc/udev/rules.d /usr/lib/udev/rules.d (strictly speaking /run/udev/rules.d and /usr/local/udev/lib/rules.d are also valid). systemd-logind grants permissions to current user logged in on console.
On Saturday 18 September 2021, Andrei Borzenkov wrote:
On 18.09.2021 05:07, Michael Hamilton wrote:
To refine my query to specifics:
Where is the list of acl's set by the defined? How would the list be amended? Can I audit the list in my running system?
ACLs are applied by systemd-logind to all device nodes that have uaccess tag. Tags are assigned by udev rules. Look at
udevadm info --export-db
and search for :uaccess:.
You can see rules with
grep -rw uaccess /etc/udev/rules.d /usr/lib/udev/rules.d
(strictly speaking /run/udev/rules.d and /usr/local/udev/lib/rules.d are also valid).
systemd-logind grants permissions to current user logged in on console.
Thanks. Just what I was looking for.
On 9/18/21 07:57, Michael Hamilton wrote:
My i2c devices /dev/i2c-* are all set to 0660, yet non-root users logged into the desktop appear to have access. How is this achieved?
Background:
During a covid-19 lockdown I wrote vdu_controls, a GUI front end to ddcutil that I use to adjust the backlights on my external monitors: Ddcutil uses VESA DDC/MCCS over i2c to interact with external monitors. Details here:
https://forums.opensuse.org/showthread.php/559401-Desktop-control-of-externa... https://www.ddcutil.com/
I recently had an enquiry from someone attempting to use vdu_controls on a non-SUSE distro. Clearly their problem is lack of permissions to /dev/i2c-*
On other distributions the permissions seem to be granted by an entry in /etc/udev/rules.d such as KERNEL=="i2c-[0-9]*", MODE="0666" ( https://www.ddcutil.com/i2c_permissions/ ).
I can't find where anything similar is set in Tumbleweed. But ddcutil is working fine, so how it a normal user getting access to /dev/i2c-*? I suspect it's due to an apparmor rule, but I can't find it.
Puzzled.
The Enlightenment desktop solves this issue by shipping a binary with a suid bit set to adjust backlights for such monitors. http://git.enlightenment.org/core/enlightenment.git/tree/src/bin/system/e_sy... -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Monday 20 September 2021, Simon Lees wrote:
On 9/18/21 07:57, Michael Hamilton wrote:
My i2c devices /dev/i2c-* are all set to 0660, yet non-root users logged into the desktop appear to have access. How is this achieved?
Background:
During a covid-19 lockdown I wrote vdu_controls, a GUI front end to ddcutil that I use to adjust the backlights on my external monitors: Ddcutil uses VESA DDC/MCCS over i2c to interact with external monitors. Details here:
https://forums.opensuse.org/showthread.php/559401-Desktop-control-of-externa... https://www.ddcutil.com/
I recently had an enquiry from someone attempting to use vdu_controls on a non-SUSE distro. Clearly their problem is lack of permissions to /dev/i2c-*
On other distributions the permissions seem to be granted by an entry in /etc/udev/rules.d such as KERNEL=="i2c-[0-9]*", MODE="0666" ( https://www.ddcutil.com/i2c_permissions/ ).
I can't find where anything similar is set in Tumbleweed. But ddcutil is working fine, so how it a normal user getting access to /dev/i2c-*? I suspect it's due to an apparmor rule, but I can't find it.
Puzzled.
The Enlightenment desktop solves this issue by shipping a binary with a suid bit set to adjust backlights for such monitors. http://git.enlightenment.org/core/enlightenment.git/tree/src/bin/system/e_sy...
It's is nice that the backlight control is built into the normal desktop controls, it shows the designers of the desktop really are thinking about usability. I do much prefer the OpenSUSE approach that restricts permissions to i2c to only the desktop user and only while they are logged in, and not to require the installation of an suid executable. Of course the two approaches can be combined so that suid is not required in enlightenment. The advantage of a more general utility such as ddcutil is that it grants access to a wider range of controls including contrast, audio-volume, input-source, etc. I wrote vdu_controls because I bought an HDR monitor. The daytime to nighttime brightness ranges from 90% down to 15%. Because of this its very handy to having the monitor controls accessable via the system-tray. Diving into settings would be less convenient. I imagine the need to adjust brightness will once again diminish as more HDR monitors include ambient light sensors.
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E. R. -
Carlos E.R.
-
J Leslie Turriff -
Michael Hamilton -
Simon Lees