Description of problem: No idea exactly whats triggering this. Here is a rough outline of what I did before these started showing up. *) upgrade system to fc29 from fc28. No prior selinux issues. *) run 'fixfiles onboot' to sort out 'pcp' problems. *) rebooted into text mode. *) started seeing sets of systemd-user-ru alerts popup in the journal. SELinux is preventing systemd-user-ru from 'rmdir' accesses on the directory services. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-user-ru should be allowed rmdir access on the services directory 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 'systemd-user-ru' --raw | audit2allow -M my-systemduserru # semodule -X 300 -i my-systemduserru.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context unconfined_u:object_r:session_dbusd_tmp_t:s0 Target Objects services [ dir ] Source systemd-user-ru Source Path systemd-user-ru Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.2-40.fc29.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.18.16-300.fc29.x86_64 #1 SMP Sat Oct 20 23:24:08 UTC 2018 x86_64 x86_64 Alert Count 1 First Seen 2018-11-01 22:15:32 CDT Last Seen 2018-11-01 22:15:32 CDT Local ID 3d12b3b5-5b9e-46be-8e9e-e9796229ffa5 Raw Audit Messages type=AVC msg=audit(1541128532.527:321): avc: denied { rmdir } for pid=8638 comm="systemd-user-ru" name="services" dev="tmpfs" ino=56958 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:session_dbusd_tmp_t:s0 tclass=dir permissive=1 Hash: systemd-user-ru,init_t,session_dbusd_tmp_t,dir,rmdir Version-Release number of selected component: selinux-policy-3.14.2-40.fc29.noarch Additional info: component: selinux-policy reporter: libreport-2.9.6 hashmarkername: setroubleshoot kernel: 4.18.16-300.fc29.x86_64 type: libreport
I also today upgraded from 28 to 29 and started seeing selinux warnings. Nothing unusual happened during the upgrade, and afaict my fedora 28 installation was very standard. The warning I'm seeing now: SELinux is preventing systemd-user-ru from read access on the directory dbus-1. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-user-ru should be allowed read access on the dbus-1 directory 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 'systemd-user-ru' --raw | audit2allow -M my-systemduserru # semodule -X 300 -i my-systemduserru.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context unconfined_u:object_r:session_dbusd_tmp_t:s0 Target Objects dbus-1 [ dir ] Source systemd-user-ru Source Path systemd-user-ru Port <Unknown> Host fedora-laptop Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.2-40.fc29.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name fedora-laptop Platform Linux fedora-laptop 4.18.16-300.fc29.x86_64 #1 SMP Sat Oct 20 23:24:08 UTC 2018 x86_64 x86_64 Alert Count 1 First Seen 2018-11-02 09:06:09 CET Last Seen 2018-11-02 09:06:09 CET Local ID 5a4248a5-f2e8-4720-a0cc-dff0e2a98724 Raw Audit Messages type=AVC msg=audit(1541145969.905:261): avc: denied { read } for pid=5971 comm="systemd-user-ru" name="dbus-1" dev="tmpfs" ino=41053 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:session_dbusd_tmp_t:s0 tclass=dir permissive=0 Hash: systemd-user-ru,init_t,session_dbusd_tmp_t,dir,read
Description of problem: After installing Fedora 29 this popped up after logging on. Version-Release number of selected component: selinux-policy-3.14.2-40.fc29.noarch Additional info: reporter: libreport-2.9.6 hashmarkername: setroubleshoot kernel: 4.18.16-300.fc29.x86_64 type: libreport
*** This bug has been marked as a duplicate of bug 1644313 ***
*** Bug 1645864 has been marked as a duplicate of this bug. ***