Starting with F41 iio-sensor-proxy no longer works on devices using HID sensors for accelerometer, compass and als. Setting enforcing to 0 fixes this. The main issue seems to be that there is a new or changed iio-sensor-proxy policy in F41 which disallows write access to sysfs_t files for iio-sensor-proxy. As part of the iio sysfs API is is sometimes necessary to write to these files so only granting ro access is not enough. I'm attaching a log file with all the AVCs from a successful start of iio-sensor-proxy after setting enforcing to 0. Reproducible: Always Steps to Reproduce: 1. Boot F41 on a 2-in-1 device with HID sensors 2. Run "systemctl status iio-sensor-proxy" Actual Results: "systemctl status iio-sensor-proxy" shows errors accessing sysfs files, iio-sensor-proxy is no running Expected Results: "systemctl status iio-sensor-proxy" shows no errors and iio-sensor-proxy is running.
Created attachment 2055970 [details] audit.log parts from starting iio-sensor-proxy with permissive=1
I noticed in the log that iio-sensor-proxy also needs access to iio chardev-s which is currently also being denied. I have multiple devices where this reproduces and I would be more the happy to test a fix.
I am hitting this as well on a MS Surface Go tablet running F41 Silverblue. I also see the same issue reported in 2319766
(In reply to Hans de Goede from comment #2) > I have multiple devices where this reproduces and I would be more the happy to test a fix. For completeness, could you post a list of them or suggest a marketing term that could be used to search for them on the web? Ordinarily, I try to reproduce selinux issues in a VM, but this appears to be a case where hardware support is required. Are there USB dongles or other peripherals that could be used for testing instead of a whole tablet?
(In reply to Steve from comment #4) > (In reply to Hans de Goede from comment #2) > > I have multiple devices where this reproduces and I would be more the happy to test a fix. > > For completeness, could you post a list of them or suggest a marketing term > that could be used to search for them on the web? > > Ordinarily, I try to reproduce selinux issues in a VM, but this appears to > be a case where hardware support is required. > > Are there USB dongles or other peripherals that could be used for testing > instead of a whole tablet? No I'm afraid that you are going to need a whole tablet or a 2-in-1 type laptop. The devices I'm seeing this on are Intel Bay Trail / Cherry Trail tablets with HID sensors, these are old and thus should be available second hand for a reasonable price (I have bought quite a few around 50 eur). But not all of these have HID sensors. Many have direct i2c-attached sensors rather then using a HID sensor-hub. Here is a list of models that I know about that do use a HID sensor hub: Dell Venue 8 Pro 5830 Dell Venue 8 Pro 5855 Dell Venue 11 Pro 7130 (not all models Bay / Cherry Trail, some more expensive) Dell Latitude 7285 (not Bay / Cherry Trail, more expensive) HP Pavilion X2 10-p002nd (many variants, only Cherry Trail models use HID sensors) Lenovo Yoga Book yb1-x91f Lenovo Miix 2 10 Lenovo ThinkPad 10 Microsoft Surface 3 (non pro model) Microsoft Surface Go 1/2/3 (?) Toshiba Click Mini L9W-B Xiaomi Mi Pad 2 Note I'm not sure if this is worth getting hw for to test. Once we have this fixed I don't expect it to regress easily.
(In reply to Hans de Goede from comment #5) Thanks for the list. I might need an excuse to get one. :-) BTW, this appears to be a duplicate: Bug 2319766 - iio-sensor-proxy systemd unit service fails
I have been experiencing this issue on Microsoft 2 in 1 and Dell Venue tablet devices since updating from Fedora 40 to 41 and would be happy to test any potential fixes/solutions.
I have the same problem with Fujitsu Lifebook U9312X after upgrading to Fedora 41. The workarounds posted here https://bugzilla.redhat.com/show_bug.cgi?id=2319766 are not working for me.
*** Bug 2324293 has been marked as a duplicate of this bug. ***
*** Bug 2324294 has been marked as a duplicate of this bug. ***
*** Bug 2324295 has been marked as a duplicate of this bug. ***
*** Bug 2324296 has been marked as a duplicate of this bug. ***
Data from this bz and duplicates: type=USER_AVC msg=audit(1730807501.646:295): pid=678 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:iiosensorproxy_t:s0 tclass=dbus permissive=1 exe="/usr/bin/dbus-broker" sauid=81 hostname=? addr=? terminal=?'UID="dbus" AUID="unset" SAUID="dbus" type=AVC msg=audit(1730807502.358:296): avc: denied { write } for pid=1706 comm="iio-sensor-prox" name="in_accel_x_en" dev="sysfs" ino=37713 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=1 type=SYSCALL msg=audit(1730807502.358:296): arch=c000003e syscall=257 success=yes exit=9 a0=ffffff9c a1=5595df7ce5d0 a2=241 a3=1b6 items=0 ppid=1 pid=1706 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iio-sensor-prox" exe="/usr/libexec/iio-sensor-proxy" subj=system_u:system_r:iiosensorproxy_t:s0 key=(null)ARCH=x86_64 SYSCALL=openat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1730807502.358:296): proctitle="/usr/libexec/iio-sensor-proxy" type=AVC msg=audit(1730807502.380:297): avc: denied { write } for pid=1706 comm="iio-sensor-prox" name="buffer" dev="sysfs" ino=37697 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1730807502.380:297): avc: denied { add_name } for pid=1706 comm="iio-sensor-prox" name="length" scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1730807502.380:297): avc: denied { create } for pid=1706 comm="iio-sensor-prox" name="length" scontext=systype=USER_AVC msg=audit(1730807501.646:295): pid=678 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:iiosensorproxy_t:s0 tclass=dbus permissive=1 exe="/usr/bin/dbus-broker" sauid=81 hostname=? addr=? terminal=?'UID="dbus" AUID="unset" SAUID="dbus" type=AVC msg=audit(1730807502.358:296): avc: denied { write } for pid=1706 comm="iio-sensor-prox" name="in_accel_x_en" dev="sysfs" ino=37713 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=1 type=SYSCALL msg=audit(1730807502.358:296): arch=c000003e syscall=257 success=yes exit=9 a0=ffffff9c a1=5595df7ce5d0 a2=241 a3=1b6 items=0 ppid=1 pid=1706 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iio-sensor-prox" exe="/usr/libexec/iio-sensor-proxy" subj=system_u:system_r:iiosensorproxy_t:s0 key=(null)ARCH=x86_64 SYSCALL=openat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1730807502.358:296): proctitle="/usr/libexec/iio-sensor-proxy" type=AVC msg=audit(1730807502.380:297): avc: denied { write } for pid=1706 comm="iio-sensor-prox" name="buffer" dev="sysfs" ino=37697 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1730807502.380:297): avc: denied { add_name } for pid=1706 comm="iio-sensor-prox" name="length" scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1730807502.380:297): avc: denied { create } for pid=1706 comm="iio-sensor-prox" name="length" scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=1 type=SYSCALL msg=audit(1730807502.380:297): arch=c000003e syscall=257 success=yes exit=8 a0=ffffff9c a1=5595df7c2380 a2=241 a3=1b6 items=1 ppid=1 pid=1706 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iio-sensor-prox" exe="/usr/libexec/iio-sensor-proxy" subj=system_u:system_r:iiosensorproxy_t:s0 key=(null)ARCH=x86_64 SYSCALL=openat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PATH msg=audit(1730807502.380:297): item=0 name="/sys/devices/pci0000:00/0000:00:0a.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001F:8086:0001.0002/HID-SENSOR-200073.4.auto/iio:device2/buffer/length" inode=37702 dev=00:17 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:sysfs_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root" type=PROCTITLE msg=audit(1730807502.380:297): proctitle="/usr/libexec/iio-sensor-proxy" type=AVC msg=audit(1730807504.605:298): avc: denied { read } for pid=1706 comm="iio-sensor-prox" name="iio:device2" dev="devtmpfs" ino=976 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 type=AVC msg=audit(1730807504.605:298): avc: denied { open } for pid=1706 comm="iio-sensor-prox" path="/dev/iio:device2" dev="devtmpfs" ino=976 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 type=SYSCALL msg=audit(1730807504.605:298): arch=c000003e syscall=257 success=yes exit=8 a0=ffffff9c a1=5595df7d31b0 a2=800 a3=0 items=0 ppid=1 pid=1706 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iio-sensor-prox" exe="/usr/libexec/iio-sensor-proxy" subj=system_u:system_r:iiosensorproxy_t:s0 key=(null)ARCH=x86_64 SYSCALL=openat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1730807504.605:298): proctitle="/usr/libexec/iio-sensor-proxy"tem_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=1 type=SYSCALL msg=audit(1730807502.380:297): arch=c000003e syscall=257 success=yes exit=8 a0=ffffff9c a1=5595df7c2380 a2=241 a3=1b6 items=1 ppid=1 pid=1706 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iio-sensor-prox" exe="/usr/libexec/iio-sensor-proxy" subj=system_u:system_r:iiosensorproxy_t:s0 key=(null)ARCH=x86_64 SYSCALL=openat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=CWD msg=audit(1730807502.380:297): cwd="/" type=PATH msg=audit(1730807502.380:297): item=0 name="/sys/devices/pci0000:00/0000:00:0a.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001F:8086:0001.0002/HID-SENSOR-200073.4.auto/iio:device2/buffer/length" inode=37702 dev=00:17 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:sysfs_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root" type=PROCTITLE msg=audit(1730807502.380:297): proctitle="/usr/libexec/iio-sensor-proxy" type=AVC msg=audit(1730807504.605:298): avc: denied { read } for pid=1706 comm="iio-sensor-prox" name="iio:device2" dev="devtmpfs" ino=976 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 type=AVC msg=audit(1730807504.605:298): avc: denied { open } for pid=1706 comm="iio-sensor-prox" path="/dev/iio:device2" dev="devtmpfs" ino=976 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 type=SYSCALL msg=audit(1730807504.605:298): arch=c000003e syscall=257 success=yes exit=8 a0=ffffff9c a1=5595df7d31b0 a2=800 a3=0 items=0 ppid=1 pid=1706 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iio-sensor-prox" exe="/usr/libexec/iio-sensor-proxy" subj=system_u:system_r:iiosensorproxy_t:s0 key=(null)ARCH=x86_64 SYSCALL=openat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1730807504.605:298): proctitle="/usr/libexec/iio-sensor-proxy" SELinux is preventing /usr/libexec/iio-sensor-proxy from 'write' accesses on the directory /sys/devices/pci0000:00/0000:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001F:8087:0AC2.0005/HID-SENSOR-200041.3.auto/iio:device0/trigger/current_trigger. SELinux is preventing /usr/libexec/iio-sensor-proxy from 'add_name' accesses on the directory /sys/devices/pci0000:00/0000:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001F:8087:0AC2.0005/HID-SENSOR-200041.3.auto/iio:device0/trigger/current_trigger SELinux is preventing /usr/libexec/iio-sensor-proxy from 'write' accesses on the file in_magn_z_en. SELinux is preventing /usr/libexec/iio-sensor-proxy from 'create' accesses on the file /sys/devices/pci0000:00/0000:00:13.0/{33AECD58-B679-4E54-9BD9-A04D34F0C226}/001F:8087:0AC2.0007/HID-SENSOR-200083.21.auto/iio:device7/trigger/current_trigger
The Framework laptops, which are traditional laptops (not tablets or 2-in-1s), also have sensors affected by this (in all models other than the original 11th-gen Intel).
My Dell XPS-15 is also affected, although it is with a different file. SELinux audit log contains: time->Thu Dec 5 13:46:37 2024 type=AVC msg=audit(1733435197.780:2246): avc: denied { read } for pid=1517 comm="iio-sensor-prox" name="event12" dev="devtmpfs" ino=897 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 System information via `inxi -F | head -n 7`: System: Host: <redacted> Kernel: 6.11.10-300.fc41.x86_64 arch: x86_64 bits: 64 Desktop: GNOME v: 47.1 Distro: Fedora Linux 41 (Forty One) Machine: Type: Laptop System: Dell product: XPS 15 7590 v: N/A serial: <superuser required> Mobo: Dell model: 018W12 v: A06 serial: <superuser required> UEFI: Dell
I am experiencing the same issue on an ASUS Zenbook 2-in-1. Is there a suggested workaround in the mean time?
(In reply to Douglas from comment #16) > I am experiencing the same issue on an ASUS Zenbook 2-in-1. Is there a > suggested workaround in the mean time? I have been executing `sudo systemctl stop iio-sensor-proxy.service` when I log in because it serves nopurpose on my Dell XPS-15, which is not a 2-in-1 laptop / tablet. Because of work and holiday obligations I have not been able to do a deep dive on this, but this is what I believe: the iio-sensor-proxy service repeatedly samples an acceleromter to determine the orientation of the screen and changes the display orientation (for example, the change from landscape to portrait orientation when one turns a tablet screen 90 degrees relative to the axis of gravity). The repeated sampling necessary for this functionality results in the repeated SELinux warnings you see. I have an XPS-13 laptop running Fedora 40 on which the iio-sensor-proxy is not enabled. I do not believe it should be running on my XPS-15 that was upgraded to Fedora 41. I could restore my last Fedora 40 backup and double-check that it was not running on Fedora 40 (which worked fine), but I am hoping this will be fixed soon. I tried `sudo systemctl --now disable iio-sensor-proxy.service` on the command line, but received this message: ```The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=, Also=, or Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled or disabled using systemctl. Possible reasons for having these kinds of units are: • A unit may be statically enabled by being symlinked from another unit's .wants/, .requires/, or .upholds/ directory. • A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. • A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). • In case of template units, the unit is meant to be enabled with some instance name specified.``` If you need the functionality of iiosensorprox, I believe you could correct this by generating a local SELinux policy module on the command line in the following way: 1. check the audit log messages using `sudo ausearch -c 'iio-sensor-prox' --raw` On my machine, this outputs 2654 audit messages. 2. create a local policy using `sudo ausearch -c 'iio-sensor-prox' --raw | audit2allow -M my-iiosensorproxy`, which will create two new files named `my-iiosensorproxy.pp` and `my-iiosensorproxy.te` in your working directory. 3. make your policy active using `sudo semodule -X 300 -i my-iiosensorproxy.pp`. On my machine, the default prioriy for the iiosensorproxy policy is 100 as shown by `sudo semodule --list-modules=full | grep iiosensorproxy`. I believe your local policy should supercede that by using a higher policy number (the argument following the -X flag). When this is fixed, you can remove your local policy using `sudo semodule -r my-iiosensorproxy`. I'm a little rusty on SELinux because it has really caused me very few problems; it was a different story twenty-odd years ago.
(this is what I believe: the iio-sensor-proxy service > repeatedly samples an acceleromter to determine the orientation of the > screen and changes the display orientation (for example, the change from > landscape to portrait orientation when one turns a tablet screen 90 degrees > relative to the axis of gravity). The repeated sampling necessary for this > functionality results in the repeated SELinux warnings you see. > If this is true, i wonder what is the point of repeatedly probe a missing sensor. Does the service expect that maybe somebody will add the sensor during the current session? Maybe the fix is to check if the accelerometer exists and if not, just fail.
(In reply to Al Pacifico from comment #17) > If you need the functionality of iiosensorprox, I believe you could correct > this by generating a local SELinux policy module on the command line in the > following way: > 1. check the audit log messages using `sudo ausearch -c 'iio-sensor-prox' > --raw` On my machine, this outputs 2654 audit messages. > 2. create a local policy using `sudo ausearch -c 'iio-sensor-prox' --raw | > audit2allow -M my-iiosensorproxy`, which will create two new files named > `my-iiosensorproxy.pp` and `my-iiosensorproxy.te` in your working directory. > 3. make your policy active using `sudo semodule -X 300 -i > my-iiosensorproxy.pp`. On my machine, the default prioriy for the > iiosensorproxy policy is 100 as shown by `sudo semodule --list-modules=full > | grep iiosensorproxy`. I believe your local policy should supercede that > by using a higher policy number (the argument following the -X flag). When > this is fixed, you can remove your local policy using `sudo semodule -r > my-iiosensorproxy`. > > I'm a little rusty on SELinux because it has really caused me very few > problems; it was a different story twenty-odd years ago. I tried this and it didn't work. After noticing that my screen didn't rotate, I tried: $ systemctl status iio-sensor-proxy.service ● iio-sensor-proxy.service - IIO Sensor Proxy service Loaded: loaded (/usr/lib/systemd/system/iio-sensor-proxy.service; static) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf, 50-keep-warm.conf Active: active (running) since Tue 2024-12-17 15:13:45 EST; 9min ago Invocation: 01dc57efe0984af0ac541df4e2d58ecf Main PID: 2125 (iio-sensor-prox) Tasks: 4 (limit: 37917) Memory: 1.7M (peak: 3.5M) CPU: 305ms CGroup: /system.slice/iio-sensor-proxy.service └─2125 /usr/libexec/iio-sensor-proxy Dec 17 15:23:23 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:23.409: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied Dec 17 15:23:24 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:24.110: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied Dec 17 15:23:24 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:24.810: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied Dec 17 15:23:25 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:25.511: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied Dec 17 15:23:26 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:26.212: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied Dec 17 15:23:26 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:26.912: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied Dec 17 15:23:27 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:27.613: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied Dec 17 15:23:28 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:28.314: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied Dec 17 15:23:29 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:29.015: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied Dec 17 15:23:29 falcon iio-sensor-proxy[2125]: ** (iio-sensor-proxy:2125): WARNING **: 15:23:29.716: Failed to open 'iio:device0' at /dev/iio:device0: Permission denied
(In reply to Al Pacifico from comment #17) > (In reply to Douglas from comment #16) > > I am experiencing the same issue on an ASUS Zenbook 2-in-1. Is there a > > suggested workaround in the mean time? > > I have been executing `sudo systemctl stop iio-sensor-proxy.service` when I > log in because it serves nopurpose on my Dell XPS-15, which is not a 2-in-1 > laptop / tablet. > > Because of work and holiday obligations I have not been able to do a deep > dive on this, but this is what I believe: the iio-sensor-proxy service > repeatedly samples an acceleromter to determine the orientation of the > screen and changes the display orientation (for example, the change from > landscape to portrait orientation when one turns a tablet screen 90 degrees > relative to the axis of gravity). The repeated sampling necessary for this > functionality results in the repeated SELinux warnings you see. > > I have an XPS-13 laptop running Fedora 40 on which the iio-sensor-proxy is > not enabled. I do not believe it should be running on my XPS-15 that was > upgraded to Fedora 41. I could restore my last Fedora 40 backup and > double-check that it was not running on Fedora 40 (which worked fine), but I > am hoping this will be fixed soon. > > I tried `sudo systemctl --now disable iio-sensor-proxy.service` on the > command line, but received this message: > ```The unit files have no installation config (WantedBy=, RequiredBy=, > UpheldBy=, > Also=, or Alias= settings in the [Install] section, and DefaultInstance= for > template units). This means they are not meant to be enabled or disabled > using systemctl. > > Possible reasons for having these kinds of units are: > • A unit may be statically enabled by being symlinked from another unit's > .wants/, .requires/, or .upholds/ directory. > • A unit's purpose may be to act as a helper for some other unit which has > a requirement dependency on it. > • A unit may be started when needed via activation (socket, path, timer, > D-Bus, udev, scripted systemctl call, ...). > • In case of template units, the unit is meant to be enabled with some > instance name specified.``` > > If you need the functionality of iiosensorprox, I believe you could correct > this by generating a local SELinux policy module on the command line in the > following way: > 1. check the audit log messages using `sudo ausearch -c 'iio-sensor-prox' > --raw` On my machine, this outputs 2654 audit messages. > 2. create a local policy using `sudo ausearch -c 'iio-sensor-prox' --raw | > audit2allow -M my-iiosensorproxy`, which will create two new files named > `my-iiosensorproxy.pp` and `my-iiosensorproxy.te` in your working directory. > 3. make your policy active using `sudo semodule -X 300 -i > my-iiosensorproxy.pp`. On my machine, the default prioriy for the > iiosensorproxy policy is 100 as shown by `sudo semodule --list-modules=full > | grep iiosensorproxy`. I believe your local policy should supercede that > by using a higher policy number (the argument following the -X flag). When > this is fixed, you can remove your local policy using `sudo semodule -r > my-iiosensorproxy`. > > I'm a little rusty on SELinux because it has really caused me very few > problems; it was a different story twenty-odd years ago. Just to let you know that this workaround fixed the screen rotation problem on my Fujitsu Lifebook U9312X. Thank you! I don't know if there's any difference between this workaround and the others, or if some recent update made a difference but nonetheless I am grateful.
This is what worked for me. ``` module fix-iio-sensor 1.0; require { type device_t; type syslogd_var_run_t; type iiosensorproxy_t; type kernel_t; type sysfs_t; class file { create write }; class dir { add_name search write }; class sock_file write; class chr_file { open read }; class unix_dgram_socket sendto; } #============= iiosensorproxy_t ============== allow iiosensorproxy_t device_t:chr_file read; allow iiosensorproxy_t device_t:chr_file open; allow iiosensorproxy_t kernel_t:unix_dgram_socket sendto; allow iiosensorproxy_t sysfs_t:dir { add_name write }; allow iiosensorproxy_t sysfs_t:file { create write }; allow iiosensorproxy_t syslogd_var_run_t:dir search; allow iiosensorproxy_t syslogd_var_run_t:sock_file write; ``` After loading this, KDE System Settings now offers an automatic option for orientation. I haven't yet figured out how to enable tablet mode automatically, but that is a different issue.
I'm trying to fix this problem (no KDE autorotate option) on a Yoga 9 14IAP7 2 in 1. I'd like to try the repair suggested by demoss.matt but don't understand what to do in the terminal to load those changes. Could someone point me in the right direction? Thank you.
@(In reply to dieterweise from comment #22) > I'm trying to fix this problem (no KDE autorotate option) on a Yoga 9 14IAP7 > 2 in 1. I'd like to try the repair suggested by demoss.matt but don't > understand what to do in the terminal to load those changes. Could someone > point me in the right direction? Thank you. this is what worked for me: 1. **Install necessary SELinux tools:** ```bash sudo dnf install policycoreutils-python-utils ``` 2. **Generate a custom policy module:** ```bash sudo ausearch -c 'iio-sensor-prox' --raw | audit2allow -M iio_sensor_proxy ``` 3. **Install the policy module:** ```bash sudo semodule -i iio_sensor_proxy.pp ``` 4. **Restart the `iio-sensor-proxy` service:** ```bash sudo systemctl restart iio-sensor-proxy ```
Thanks for those commands! They worked. Autorotate finally appears as an option again, and it works when applied. As a note, the "apply automatic rotation only in tablet mode" option is not changing anything - the screen rotates in laptop mode too. But for me this isn't important.
Also worked for me on a Zenbook OLED Flip. I would like to know what a permanent fix would be, as this workaround would be forgotten and lost upon reinstall. The detection of tablet mode seems to be a separate issue as different laptop models can use different sensors to report the fold event. I believe there's some if clauses in the amd gpu code in the kernel that check for certain laptop models by hardcoded string values. I forget exactly, but seems infeasible to have to keep adding new models like this. I would love auto rotate AND disabling the keyboard when in tablet mode to work. It seems like more and more laptops come with touch screens and ability to fold over into a tablet, but not sure how to track if this is already listed as a feature request.
Lenovo ThinkPad X13 Yoga Gen 2 is also affected. Regarding the steps in comment #23 by victor.c.pang: This works for me, but I had to repeat steps 2-4 a few times until the generated policy contained all relevant permissions. The result was the same as the one in #21 by demoss.matt+rh. Having essentially no knowledge of selinux, it took me some time to research how to apply that, however. The steps seems to be: - save the policy given in #21 to `iio_sensor_proxy.te` - compile to a module with `checkmodule -M -m iio_sensor_proxy.te -o iio_sensor_proxy.mod` (not sure whether the `-M` is required) - package the module using `semodule_package -o iio_sensor_proxy.pp -m iio_sensor_proxy.mod` - install and load the policy package with `sudo semodule -i iio_sensor_proxy.pp` - reload the service: `sudo systemctl restart iio-sensor-proxy It would be great if fixing this properly could be prioritized; the number of sharp edges when dealing with 2in1/tablet devices on Linux/Fedora is unfortunately still very high.
I should add that this is not just a two-in-one device issue, as repeated SELinux messages appeared on my Dell laptop (XPS-15 7590) which is not a two-in-one. Not needing screen auto-rotation, I had the luxury of simply masking the iiosensorproxy service. Agree with wisp3rwind that this, unless addressed, will be forgotten on an update and be a repeated annoyance. Actually, it led me to postpone upgrading my other machines to Fedora 41, out of concern other gotchas lurk. I have been using what is now Fedora since it was RedHat Linux 6.2 more than twenty-five years ago, and I can't recall a similarly irksome issue introduced by an update since the single-digit versions of Fedora. If I were a new Fedora Linux user who had just installed Fedora 41 on my older laptop and encountered this, I'm certain I'd be convinced the entire distro was junk.
*** Bug 2324953 has been marked as a duplicate of this bug. ***
*** Bug 2327725 has been marked as a duplicate of this bug. ***
*** Bug 2322080 has been marked as a duplicate of this bug. ***
*** Bug 2330478 has been marked as a duplicate of this bug. ***
*** Bug 2336622 has been marked as a duplicate of this bug. ***
*** Bug 2336971 has been marked as a duplicate of this bug. ***
*** Bug 2338756 has been marked as a duplicate of this bug. ***
*** Bug 2338758 has been marked as a duplicate of this bug. ***
*** Bug 2338956 has been marked as a duplicate of this bug. ***
*** Bug 2341739 has been marked as a duplicate of this bug. ***
*** Bug 2324954 has been marked as a duplicate of this bug. ***
FEDORA-2025-9da160c869 (selinux-policy-41.30-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-9da160c869
FEDORA-2025-9da160c869 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-9da160c869` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-9da160c869 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
This update did not solve the problem with auto-rotation on my Thinkpad Yoga X1 Gen 7. selinux-policy-41.30-1.fc41.noarch selinux-policy-targeted-41.30-1.fc41.noarch iio-sensor-proxy-3.5-5.fc41.x86_64 The workaround of killing iio-sensor-proxy and restarting as root before logging in does work but it is annoying.
The FEDORA-2025-9da160c869 update did eliminate the repeated AVC denial messages on my Fedora 41 Dell XPS-15 7590 laptop. selinux-policy-41.30-1.fc41.noarch selinux-policy-targeted-41.30-1.fc41.noarch iio-sensor-proxy-3.5-5.fc41.x86_64
I should add (after providing feedback at https://bodhi.fedoraproject.org/updates/FEDORA-2025-9da160c869 and seeing the issues addressed), on my Dell XPS-15 7590 laptop, those looked like: type=AVC msg=audit(1738429728.152:734): avc: denied { open } for pid=1549 comm="iio-sensor-prox" path="/dev/input/event12" dev="devtmpfs" ino=907 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 type=AVC msg=audit(1738429728.152:735): avc: denied { write } for pid=1549 comm="iio-sensor-prox" name="socket" dev="tmpfs" ino=60 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=sock_file permissive=0
I added an override to test this ``` sudo rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2025-9da160c869 ``` However I am still getting permissions errors in iio-sensor-proxy on my Surface Go. Auto rotation is not working as a result. ``` Feb 01 16:29:56 fedora iio-sensor-proxy[1120]: ** (iio-sensor-proxy:1120): WARNING **: 16:29:56.975: Failed to open 'iio:device2' at /dev/iio:device2: Permission denied ```
FEDORA-2025-62c612355c has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-62c612355c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-62c612355c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-62c612355c (selinux-policy-41.31-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
Works for me now.
There is very similar or even exactly the same issue in Fedora 42 now. https://discussion.fedoraproject.org/t/issue-with-selinux-and-iio-sensor-prox-in-fedora-42/155067/2 $ sealert -l a43e0d3c-dfc0-48cc-904a-3487fcb2d0ae SELinux is preventing iio-sensor-prox from using the sys_admin capability. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that iio-sensor-prox should have the sys_admin capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'iio-sensor-prox' --raw | audit2allow -M my-iiosensorprox # semodule -X 300 -i my-iiosensorprox.pp Additional Information: Source Context system_u:system_r:iiosensorproxy_t:s0 Target Context system_u:system_r:iiosensorproxy_t:s0 Target Objects Unknown [ capability ] Source iio-sensor-prox Source Path iio-sensor-prox Port <Unknown> Host fedora Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-41.43-1.fc42.noarch Local Policy RPM selinux-policy-targeted-41.43-1.fc42.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name fedora Platform Linux fedora 6.14.9-300.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 29 14:27:53 UTC 2025 x86_64 Alert Count 10 First Seen 2025-06-08 10:22:51 IDT Last Seen 2025-06-08 10:22:51 IDT Local ID a43e0d3c-dfc0-48cc-904a-3487fcb2d0ae Raw Audit Messages type=AVC msg=audit(1749367371.436:112): avc: denied { sys_admin } for pid=1185 comm="iio-sensor-prox" capability=21 scontext=system_u:system_r:iiosensorproxy_t:s0 tcontext=system_u:system_r:iiosensorproxy_t:s0 tclass=capability permissive=0 Hash: iio-sensor-prox,iiosensorproxy_t,iiosensorproxy_t,capability,sys_admin BTW why it’s iio-sensor-prox and not iio-sensor-proxy? Looks like a typo somewhere. The real package name is longer: https://packages.fedoraproject.org/pkgs/iio-sensor-proxy/