Description of problem: setroubleshoot seems functional. 5 errors are logged on every boot to the journal. Journal entries on boot: setroubleshoot[2246]: cannot chmod /var/lib/setroubleshoot/setroubleshoot_database.xml to 600 [Operation not permitted] setroubleshoot[2246]: cannot chown /var/lib/setroubleshoot/setroubleshoot_database.xml to setroubleshoot:setroubleshoot [Operation not permitted] setroubleshootd[2246]: Permission deniedPermission deniedI/O warning : failed to load external entity "/var/lib/setroubleshoot/setroubleshoot_database.xml" setroubleshoot[2246]: read_xml_file() libxml2.parserError: xmlParseFile() failed setroubleshoot[2246]: cannot chmod /var/lib/setroubleshoot/email_alert_recipients to 600 [Operation not permitted] setroubleshoot[2246]: cannot chown /var/lib/setroubleshoot/email_alert_recipients to setroubleshoot:setroubleshoot [Operation not permitted] How reproducible: Always, on boot Steps to Reproduce: 1. Install setroubleshoot 2. Reboot Actual results: setroubleshoot seems functional. 5 errors are logged to the journal. Expected results: No errors are logged.
Please run the following command and let us know what is the output: # ls -alZ /var/lib/setroubleshoot/
I'm NOT able to reproduce the problem on my Fedora 35 VM. Here is the output I see on my VM: # ls -alZ /var/lib/setroubleshoot/ total 12 drwx------. 2 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 4096 Oct 13 03:03 . drwxr-xr-x. 29 root root system_u:object_r:var_lib_t:s0 4096 Oct 13 03:01 .. -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 Oct 13 03:03 email_alert_recipients -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 2752 Oct 13 03:03 setroubleshoot_database.xml # # rpm -qa setr\* | sort setroubleshoot-plugins-3.3.14-3.fc35.noarch setroubleshoot-server-3.3.26-5.fc35.x86_64 #
# ls -alZ /var/lib/setroubleshoot/ total 4 drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 10. Okt 23:02 . drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 840 10. Okt 23:02 .. -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 10. Okt 23:02 email_alert_recipients -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 334 13. Okt 00:52 setroubleshoot_database.xml # rpm -qa setr\* | sort setroubleshoot-3.3.26-5.fc35.x86_64 setroubleshoot-plugins-3.3.14-3.fc35.noarch setroubleshoot-server-3.3.26-5.fc35.x86_64 I noticed the following warning is logged in addition: dbus-broker-launch[1811]: Service file '/usr/share//dbus-1/services/sealert.service' is not named after the D-Bus name 'org.fedoraproject.Setroubleshootd'.
> I'm NOT able to reproduce the problem on my Fedora 35 VM. Indeed. Just looked through journalctl and the first boot after installation of setroubleshoot shows the error, boots afterwards do no longer show it. That's also shown by the owner actually being setroubleshoot:setroubleshoot. I've been testing it on Fedora Silverblue 35 - if it makes a difference for file ownerships in /var/...
Ohhh! Found something interesting on a Silverblue 34 machine. Here the error is logged every boot and... look at this: # ls -alZ /var/lib/setroubleshoot/ total 36 drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 2. Dez 2020 . drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 798 15. Sep 19:20 .. -rw-------. 1 gnome-initial-setup 966 system_u:object_r:setroubleshoot_var_lib_t:s0 0 2. Dez 2020 email_alert_recipients -rw-------. 1 gnome-initial-setup 966 system_u:object_r:setroubleshoot_var_lib_t:s0 36380 17. Jan 2021 setroubleshoot_database.xml
The same on a clean Fedora 34 installation: # ls -alZ /var/lib/setroubleshoot/ total 8 drwx------. 2 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 71 Oct 13 12:40 . drwxr-xr-x. 59 root root system_u:object_r:var_lib_t:s0 4096 Oct 13 12:36 .. -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 Oct 13 12:40 email_alert_recipients -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 239 Oct 13 12:40 setroubleshoot_database.xml
Good catch! The ownership values of gnome-initial-setup:966 are definitely wrong.
Try: # echo "Z /var/lib/setroubleshoot - setroubleshoot setroubleshoot -" > /etc/tmpfiles.d/setroubleshoot.conf # reboot It should fix your problem (unless silverblue handles files in /etc/ specifically)
Hi Petr, This indeed fixed the issue (see log below). Thank you! Do you have a guess what could have caused this? Can I remove /etc/tmpfiles.d/setroubleshoot.conf afterwards? # ll /etc/tmpfiles.d/ total 0 # ls -alZ /var/lib/setroubleshoot/ total 36 drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 2. Dez 2020 . drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 798 15. Sep 19:20 .. -rw-------. 1 gnome-initial-setup 966 system_u:object_r:setroubleshoot_var_lib_t:s0 0 2. Dez 2020 email_alert_recipients -rw-------. 1 gnome-initial-setup 966 system_u:object_r:setroubleshoot_var_lib_t:s0 36380 17. Jan 2021 setroubleshoot_database.xml # echo "Z /var/lib/setroubleshoot - setroubleshoot setroubleshoot -" > /etc/tmpfiles.d/setroubleshoot.conf # reboot # ls -alZ /var/lib/setroubleshoot/ total 32 drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 2. Dez 2020 . drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 798 15. Sep 19:20 .. -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 2. Dez 2020 email_alert_recipients -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 31030 13. Okt 19:17 setroubleshoot_database.xml $ journalctl -p4 -b | grep "cannot chown" <empty - The errors are no longer logged>
Add: - /etc/tmpfiles.d/setroubleshoot.conf can be removed afterwards - If I understand tmpfiles.d correctly this is equivalent to running # restorecon and # chown on /var/lib/setroubleshoot/ recursively
I guess this is caused by the way how setroubleshoot was installed. How did you install it? Using /etc/tmpfiles.d/setroubleshoot.conf was just a concept whether we could use the same line in /usr/lib/tmpfiles.d/setroubleshoot.conf and workaround this problem on every boot. > - /etc/tmpfiles.d/setroubleshoot.conf can be removed afterwards > - If I understand tmpfiles.d correctly this is equivalent to running # > restorecon and # chown on /var/lib/setroubleshoot/ recursively Yes, but it's run on every boot.
I installed it on Silverblue 34 & 35 using a simple `rpm-ostree install setroubleshoot`. Now it gets interesting: - Installed setroubleshoot on a freshly setup Silverblue 35 machine on 10th of October - That's the machine I mentioned in a previous post: "the first boot after installation of setroubleshoot shows the error, boots afterwards do no longer show it. That's also shown by the owner actually being setroubleshoot:setroubleshoot." - Looking into journalctl the error returned on 14th of October - This machine is my main dev machine. It is rebooted at least once daily - Assumption: 14th October could be the first "rpm-ostree update" after the initial installation of setroubleshoot Anyway the owners are now: # ls -alZ /var/lib/setroubleshoot/ total 4 drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 10. Okt 23:02 . drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 840 10. Okt 23:02 .. -rw-------. 1 saslauth setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 10. Okt 23:02 email_alert_recipients -rw-------. 1 saslauth setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 334 13. Okt 00:52 setroubleshoot_database.xml
I reported this problem at https://github.com/coreos/rpm-ostree/issues/3179
Pushed an initial set of updates in https://src.fedoraproject.org/rpms/setroubleshoot/pull-request/29
FEDORA-2022-611d8856d5 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-611d8856d5
FEDORA-2022-611d8856d5 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-611d8856d5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-611d8856d5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-611d8856d5 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Can confirm the issue is fixed after updating to setroubleshoot-3.3.28-3.fc35.x86_64