Description of problem: I ran "fixfiles onboot" aka relabeling and noticed it complained about multiple definisions of some log file. So at midnight I got this SELinux alert, but remembering that warning I took a moment to check and take a look: # ll -Z /var/log/boot.log -rw-r--r--. 2 root root system_u:object_r:plymouthd_spool_t:s0 151091 12-27 19:22 /var/log/boot.log # restorecon -v /var/log/boot.log Relabeled /var/log/boot.log from system_u:object_r:plymouthd_spool_t:s0 to system_u:object_r:plymouthd_var_log_t:s0 # ll -Z /var/log/boot.log -rw-r--r--. 2 root root system_u:object_r:plymouthd_var_log_t:s0 151091 12-27 19:22 /var/log/boot.log # restorecon -v /var/spool/plymouth/boot.log Relabeled /var/spool/plymouth/boot.log from system_u:object_r:plymouthd_var_log_t:s0 to system_u:object_r:plymouthd_spool_t:s0 # ll -Z /var/log/boot.log -rw-r--r--. 2 root root system_u:object_r:plymouthd_spool_t:s0 151091 12-27 19:22 /var/log/boot.log It's a hardlinked file that resides in two directories with two different labels, and autorelabel breaks that by picking the wrong one, I guess. Not many people relabel their F31s I imagine, so this doesn't pop up often. It wasn't actually necessary for me either, I was only making sure everything is fine while investigating an unrelated issue. SELinux is preventing logrotate from 'getattr' accesses on the plik /var/log/boot.log. ***** Plugin restorecon (99.5 confidence) suggests ************************ Aby naprawić etykietę. domyślna etykieta /var/log/boot.log powinna wynosić plymouthd_var_log_t. Then można wykonać polecenie restorecon. Próba dostępu mogła zostać zatrzymana z powodu niewystarczających uprawnień dostępu do katalogu nadrzędnego, więc należy odpowiednio zmienić poniższe polecenie. Do # /sbin/restorecon -v /var/log/boot.log ***** Plugin catchall (1.49 confidence) suggests ************************** Aby logrotate powinno mieć domyślnie getattr dostęp do boot.log file. Then proszę to zgłosić jako błąd. Można utworzyć lokalny moduł polityki, aby umożliwić ten dostęp. Do można tymczasowo zezwolić na ten dostęp wykonując polecenia: # ausearch -c 'logrotate' --raw | audit2allow -M my-logrotate # semodule -X 300 -i my-logrotate.pp Additional Information: Source Context system_u:system_r:logrotate_t:s0 Target Context system_u:object_r:plymouthd_spool_t:s0 Target Objects /var/log/boot.log [ file ] Source logrotate Source Path logrotate Port <Nieznane> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.4-43.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.4.5-300.fc31.x86_64 #1 SMP Thu Dec 19 19:37:41 UTC 2019 x86_64 x86_64 Alert Count 2 First Seen 2019-12-28 00:00:01 CET Last Seen 2019-12-28 00:00:01 CET Local ID 38494206-41d2-4e4a-a5d1-f12582a9a0a8 Raw Audit Messages type=AVC msg=audit(1577487601.405:8275): avc: denied { getattr } for pid=58954 comm="logrotate" path="/var/log/boot.log" dev="md1" ino=3213411 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:plymouthd_spool_t:s0 tclass=file permissive=0 Hash: logrotate,logrotate_t,plymouthd_spool_t,file,getattr Version-Release number of selected component: selinux-policy-3.14.4-43.fc31.noarch Additional info: component: selinux-policy reporter: libreport-2.11.3 hashmarkername: setroubleshoot kernel: 5.4.5-300.fc31.x86_64 type: libreport
HI, Could you please attach output of: # semanage export Thanks, Lukas.
Created attachment 1651334 [details] semanage export output
Hi Leszek, Are you sure that running restorecon doesn't help? In policy "/var/log/boot.log" is defined as plymouthd_var_log_t and I'm not able to reproduce it. Just to be sure, could you ran restorecon once more? # restorecon -Rv /var/log Thanks, Lukas.
Yes, as I wrote in the original report, I can fix (and have fixed) this instantly by doing: restorecon -v /var/log/boot.log But I can also still break it instantly by doing: restorecon -v /var/spool/plymouth/boot.log Of course you might ask why would I break it intentionally, even if there's a command for that ;) The problem is that autorelabel goes through /var/spool after /var/log (at least on my system), so autorelabel mislabels this file, due to it being hardlinked in two locations. And this breaks logrotate operating on said file. If this needs to be hardlinked (as opposed to symbolic link or just configuring plymouth to use /var/log and not /var/spool/plymouth), then perhaps the policy should assign plymouthd_var_log_t label for /var/spool/plymouth/boot.log instead of plymouthd_spool_t?
No, I see. Thanks for explanation. Adding fixes: commit 8f465f97ef0153ade576ad203ed6d172cbf263bc (HEAD -> rawhide) Author: Lukas Vrabec <lvrabec> Date: Fri Jan 17 12:04:16 2020 +0100 Label /var/spool/plymouth/boot.log as plymouthd_var_log_t Resolves: rhbz#1786852
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
selinux-policy-3.14.4-45.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bb42099a17
selinux-policy-3.14.4-45.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
I confirm the update fixes the issue. Thank you! BTW, just last Friday I encountered exactly the same issue after autorelabel on RHEL 7.6 EUS (selinux-policy-3.13.1-229.el7_6.15), I wonder if this fix will somehow make its way into 7.8, are some of the policy sources shared?
Leszek, Please note this bug tracking system is not a mechanism for requesting support for Red Hat Enterprise Linux, and we are not able to guarantee the timeliness or suitability of a resolution. If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution. Also note RHEL 7 reached Maintenance Support 1 Phase which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. https://access.redhat.com/support/policy/updates/errata/
Yes, I fully understand, I mainly mentioned this as a curious coincidence. Thanks for your patience :)