Description of problem: this happened after 1st reboot after upgrade of fedora30 to fedora31 SELinux is preventing (systemd) from 'entrypoint' accesses on the file /usr/lib/systemd/systemd. ***** Plugin restorecon (99.5 confidence) suggests ************************ If you want to fix the label. /usr/lib/systemd/systemd default label should be init_exec_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /usr/lib/systemd/systemd ***** Plugin catchall (1.49 confidence) suggests ************************** If you believe that (systemd) should be allowed entrypoint access on the systemd file 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)' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0 Target Context system_u:object_r:lib_t:s0 Target Objects /usr/lib/systemd/systemd [ file ] Source (systemd) Source Path (systemd) Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages systemd-243.8-1.fc31.x86_64 SELinux Policy RPM selinux-policy-3.14.4-50.fc31.noarch Local Policy RPM selinux-policy-targeted-3.14.4-50.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 5.5.13-200.fc31.x86_64 #1 SMP Wed Mar 25 21:55:30 UTC 2020 x86_64 x86_64 Alert Count 27 First Seen 2020-02-23 09:09:44 IST Last Seen 2020-04-03 17:35:47 IDT Local ID b19fd378-ecf0-4691-9696-272e7ee8b7ab Raw Audit Messages type=AVC msg=audit(1585924547.511:318): avc: denied { entrypoint } for pid=2504 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="dm-1" ino=1185402 scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file permissive=1 Hash: (systemd),unconfined_t,lib_t,file,entrypoint Version-Release number of selected component: selinux-policy-3.14.4-50.fc31.noarch Additional info: component: selinux-policy reporter: libreport-2.12.0 hashmarkername: setroubleshoot kernel: 5.5.13-200.fc31.x86_64 type: libreport
Hi, The systemd executable as mentioned in the setroubleshoot report has incorrect label. Along with the restorecon plugin suggestion, you can fix the label with a single command: # /sbin/restorecon -v /usr/lib/systemd/systemd It would be interesting though to know if, before the update, the label was correct, everything worked as expected, no denial was reported, as well as during the update process there was no error reported. Personally, I cannot reproduce it, an update always succeeds.
(In reply to Zdenek Pytela from comment #1) > Hi, > > The systemd executable as mentioned in the setroubleshoot report has > incorrect label. Along with the restorecon plugin suggestion, you can fix > the label with a single command: > > # /sbin/restorecon -v /usr/lib/systemd/systemd > > It would be interesting though to know if, before the update, the label was > correct, i don't know, is there a way to check that? > everything worked as expected, no denial was reported, didn't see this SElinux issue before the upgrade > as well as > during the update process there was no error reported. Personally, I cannot > reproduce it, an update always succeeds. the upgrade went mostly well, but got stuck on 100% - had to restart the machine how do i see the system logs from the upgrade?
Hi Yuval, Can you please describe how did you upgrade your system? Btw. this looks like issue in upgrade process not issue in systemd. Thanks, Lukas.
I followed the instructions from here: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ only issue was that after reboot, it got stuck on "100%" for a long time. i rebooted manually, and then everything started ok with fedora 31. only issue was that SELinux warning I got on the first reboot.
I am seeing this too in openQA tests. It is actually happening when booting a disk image created with virt-install: I've done nothing to this image, just creating it with virt-install and trying to boot from it is enough to cause the problem. This seems to have started happening some time between April 22 and April 27. openQA prod is currently using an image built on April 22 which boots fine, but the bug has been happening on openQA staging since the image in question was rebuilt there on April 27. It is still happening now, if I build a fresh image, it is affected by the bug. The kickstart used for the image build is https://pagure.io/fedora-qa/createhdds/blob/master/f/desktopencrypt.ks . The command used to build the image is: virt-install --disk size=20,path=disk_f31_desktopencrypt_x86_64.img.tmp --os-variant fedora31 -x inst.ks=file:/desktopencrypt.ks --initrd-inject /root/createhdds/desktopencrypt.ks --location https://download.fedoraproject.org/pub/fedora/linux/releases/31/Everything/x86_64/os/ --name createhdds --memory 2048 --noreboot --wait -1 --graphics vnc --noautoconsole --network user CCing Cole for virt-install angle.
ah, another key difference between working (prod) and broken (stg) deployments: Fedora release. Prod is still on Fedora 31, for now. Stg is on Fedora 32. It looks like the image in question was rebuilt after I upgraded stg to F32, so the problem here may be when the image is built on F32...
First I've heard of an issue like this, not sure if or how host virt stack would play into it
Ugh, so it turned out something was breaking the rebuild of base disk images on openQA production instance...I fixed that, all the images got rebuilt, and now this is broken there too :( So it's not about the host virt stack, I think, as we're hitting this with images built on F31 too. The encryption also doesn't seem to be involved: the non-encrypted base disk, which uses https://pagure.io/fedora-qa/createhdds/blob/master/f/desktop.ks , is similarly broken, and that's causing tons of F31 update tests to fail :( I'll have to see if I can figure out a workaround today.
So, poking an affected image locally, one odd thing I notice is that selinux-policy-minimum was installed as well as selinux-policy-targeted . That seems odd and I can't see a very obvious reason why. I'm trying a build with '-selinux-policy-minimum' in the kickstart to see if that helps.
so yeah, adding `-selinux-policy-minimum` to the kickstart helps. still, it seems like a bug, or two bugs: having that package installed presumably shouldn't lead to this happening, and also why is it getting pulled in at all? Yuval, do you have selinux-policy-minimum installed?
No package in Fedora should be requiring selinux-policy-minimum, they should be requiring selinux-policy-base. I wonder if there is a package that made this mistake.
Yeah, I still don't know why it started showing up in the image builds in my case. It doesn't seem to be a hard dependency, as it can be removed after install and nothing else goes away with it. I can't find it listed in comps or fedora-kickstarts. So I didn't solve that mystery yet.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.