Bug 1782225
| Summary: | "Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1784" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tim Landscheidt <tim> |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 30 | CC: | amurdaca, belegdol, customercare, dwalsh, extras-qa, fedora, jchaloup, jonemilj, lsm5, lvrabec, mgrepl, p1mail2015, plautrba, prd-fedora, rh.container.bot, sheepdestroyer, stefan.hoelldampf, tim, tony, zpytela |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1775994 | Environment: | |
| Last Closed: | 2020-05-26 14:31:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tim Landscheidt
2019-12-11 13:11:22 UTC
Since this has not been update in months, it must be caused by an updated selinux-policy package. I believe I hit this same issue, however in a perhaps a bit more severe form. I attempted to do the normal dnf update, it updated selinux-policy* packages as follows:
Upgrade selinux-policy-3.14.4-43.fc31.noarch @updates
Upgraded selinux-policy-3.14.4-40.fc31.noarch @@System
Upgrade selinux-policy-targeted-3.14.4-43.fc31.noarch @updates
Upgraded selinux-policy-targeted-3.14.4-40.fc31.noarch @@System
With the following related errors in the log:
2 Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1784
3 Failed to generate binary
4 /usr/sbin/semodule: Failed!
I foolishly attempted to autorelabel after this happen, which resulted in a broken system(relabel failed with some errors), where systemd was not allowed starting new processes, so no logins were possible. I had to disable selinux (boot: selinux=0) and try to downgrade the packages and then relabel to get login with selinux working again.
Command Line : downgrade selinux-policy-targeted selinux-policy
Packages Altered:
Downgrade flatpak-1.4.3-1.fc31.x86_64 @fedora
Downgraded flatpak-1.4.3-3.fc31.x86_64 @@System
Downgrade flatpak-selinux-1.4.3-1.fc31.x86_64 @fedora
Downgraded flatpak-selinux-1.4.3-3.fc31.noarch @@System
Downgrade flatpak-session-helper-1.4.3-1.fc31.x86_64 @fedora
Downgraded flatpak-session-helper-1.4.3-3.fc31.x86_64 @@System
Downgrade selinux-policy-3.14.4-37.fc31.noarch @fedora
Downgraded selinux-policy-3.14.4-43.fc31.noarch @@System
Downgrade selinux-policy-targeted-3.14.4-37.fc31.noarch @fedora
Downgraded selinux-policy-targeted-3.14.4-43.fc31.noarch @@System
No errors in the log, and after that I did: sudo touch /.autorelabel
which successfully ran without errors this time.
I'm unsure why downgrade skipped 3.14.4-40, but now it seem to work, so I guess something weird happens in one of the updates after version '37' in the policy packages.
Try dnf reinstall container-selinux (In reply to Daniel Walsh from comment #3) > Try dnf reinstall container-selinux I should've perhaps stated this explicitly in my comment, but I hit this on fedora 31. When that is said, I also tried 'dnf reinstall container-selinux', but I don't have that installed. As well as reinstalling all the packages with 'selinux' in its name I found by doing 'rpm -qa | grep selinux', but neither of those had any effect on the state of the system it seemed. I might have been to quick to judge what may have caused my errors, although the error looks the same as in this ticket, this other ticket https://bugzilla.redhat.com/show_bug.cgi?id=1775994 I see that these may be fixed by reinstalling the container package, which might indicate there are different issues with similar symptoms. For now I can live with an old flatpak version and older policies(I think). I just did a new test to try to update the policy package, after I managed to get my system relabeled and all good. And I manage to trigger the same scenario: Running scriptlet: selinux-policy-targeted-3.14.4-43.fc31.noarch 2/10 Conflicting name type transition rules Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1784 Failed to generate binary /usr/sbin/semodule: Failed! Upgrading : flatpak-selinux-1.4.3-3.fc31.noarch 3/10 Running scriptlet: flatpak-selinux-1.4.3-3.fc31.noarch 3/10 Conflicting name type transition rules Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1784 Failed to generate binary /usr/sbin/semodule: Failed! Upgrading : flatpak-session-helper-1.4.3-3.fc31.x86_64 4/10 Running scriptlet: flatpak-1.4.3-3.fc31.x86_64 5/10 Upgrading : flatpak-1.4.3-3.fc31.x86_64 5/10 error: lsetfilecon: (/usr/libexec/flatpak-system-helper;5df31290, system_u:object_r:flatpak_helper_exec_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed Error unpacking rpm package flatpak-1.4.3-3.fc31.x86_64 Cleanup : flatpak-selinux-1.4.3-1.fc31.x86_64 6/10 error: unpacking of archive failed on file /usr/libexec/flatpak-system-helper;5df31290: cpio: (error 0x2) error: flatpak-1.4.3-3.fc31.x86_64: install failed error: flatpak-1.4.3-1.fc31.x86_64: erase skipped So it happens when updating the selinux-policy-targeted package. When this happens, sealert starts spamming processes being blocked popup window in gnome. And I assume if I do a restart now that I am not able to log in again. I tested again because I wanted to see if my initial state of the system was ok, to make sure the package updates was not foiled by files being labeled wrong before the update. And since this happens with a "clean" system before updating, I assume that there is something that the scriptlets does which goes horribly wrong. However this might not be related to the original issue in this ticket, so I'm unsure if I'm currently hijacking the ticket, if I manage to figure out exactly what is causing it I'll update. I looked into the comments over at https://bugzilla.redhat.com/show_bug.cgi?id=1778612#c3 And I don't know the spec files very well but I guess as commented over there the spec changes might need to be done on the selinux-policy spec file as well. The behaviour which seemed to be changed in the container spec file, aligns with what I see on my end as well, that something goes wrong with the relabeling. However unlike the container spec failure, when updating the selinux-policy packages the effects seem more severe. I'm unsure if it is only me who hit this for some reason, but updating the selinux-policy packages to a version hitting this problem, basically breaks the system and at least in my case forced me to disable selinux to be able to log back in. So it might be a critical thing to fix, if my scenario is a common one. I assume that most users don't actually know how to work around it, as there are no error messages when trying to log back in, it just won't let you. Assuming this also applies to f30. I tested a workaround to the update issue of selinux-policy and selinux-policy-targeted by installing container-selinux(I did not have this installed before), with the theory being that one of the scriptlets in that package would as a side effect resolve the label issues that the other packages hit when being upgraded. While the upgrade of selinux-policy and selinux-policy-targeted upgrades got the same expected errors when upgrading to 3.14.4-43, installing container-selinux afterwards somehow resolved the label issues(and the spamming of selinux warnings/popups) probably because of the changes done to the scriptlets in respect to labeling. So this workaround can perhaps be of use for others as well, if you need to upgrade the selinux packages for some reason. As a test to see if it worked, I reinsalled selinux-policy-* packages to see that the scriptlets ran fine, and they did, so it appears that the workaround at least partially worked, although I'm unsure what happens if I remove container-selinux so I'll just let it be for now. F29->F30 dnf sysupgrade: 7.1.2020 Aktualisieren : net-snmp-libs-1:5.8-10.fc30.x86_64 552/2265 Ausgeführtes Scriptlet: httpd-filesystem-2.4.41-6.1.fc30.noarch 553/2265 Aktualisieren : httpd-filesystem-2.4.41-6.1.fc30.noarch 553/2265 Aktualisieren : rpm-plugin-selinux-4.14.2.1-5.fc30.x86_64 554/2265 Aktualisieren : selinux-policy-3.14.3-53.fc30.noarch 555/2265 Ausgeführtes Scriptlet: selinux-policy-3.14.3-53.fc30.noarch 555/2265 Ausgeführtes Scriptlet: selinux-policy-targeted-3.14.3-53.fc30.noarch 556/2265 Aktualisieren : selinux-policy-targeted-3.14.3-53.fc30.noarch 556/2265 Ausgeführtes Scriptlet: selinux-policy-targeted-3.14.3-53.fc30.noarch 556/2265 Conflicting name type transition rules Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1780 Failed to generate binary /usr/sbin/semodule: Failed! Aktualisieren : dbus-tools-1:1.12.16-1.fc30.x86_64 557/2265 Aktualisieren : iputils-20180629-4.fc30.x86_64 558/2265 Ausgeführtes Scriptlet: iputils-20180629-4.fc30.x86_64 558/2265 Aktualisieren : python3-libcomps-0.1.14-1.fc30.x86_64 655/2265 Aktualisieren : python3-sss-murmur-2.2.2-3.fc30.x86_64 656/2265 Ausgeführtes Scriptlet: unbound-libs-1.9.6-1.fc30.x86_64 657/2265 Aktualisieren : unbound-libs-1.9.6-1.fc30.x86_64 657/2265 Warnung: /var/lib/unbound/root.key als /var/lib/unbound/root.key.rpmsave gesichert ... Installieren : systemtap-sdt-devel-4.2-1.fc30.x86_64 666/2265 Aktualisieren : python3-audit-3.0-0.15.20191104git1c2f876.fc30.x86_64 667/2265 Aktualisieren : python3-policycoreutils-2.9-4.fc30.noarch 668/2265 Aktualisieren : policycoreutils-python-utils-2.9-4.fc30.noarch 669/2265 Ausgeführtes Scriptlet: mysql-selinux-1.0.0-8.fc30.noarch 670/2265 Aktualisieren : mysql-selinux-1.0.0-8.fc30.noarch 670/2265 Ausgeführtes Scriptlet: mysql-selinux-1.0.0-8.fc30.noarch 670/2265 Conflicting name type transition rules Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1780 Failed to generate binary /usr/sbin/semodule: Failed! Aktualisieren : python3-asn1crypto-0.24.0-6.fc30.noarch 671/2265 Aktualisieren : python3-cryptography-2.6.1-1.fc30.x86_64 672/2265 Aktualisieren : python3-jwcrypto-0.6.0-2.fc30.noarch 673/2265 Aktualisieren : python3-augeas-0.5.0-14.fc30.noarch 674/2265 Aktualisieren : python3-chardet-3.0.4-9.fc30.noarch 675/2265 *** Bug 1785443 has been marked as a duplicate of this bug. *** Something is still wrong!! dnf update .... Upgrading : selinux-policy-3.14.4-48.fc31.noarch Running scriptlet: selinux-policy-3.14.4-48.fc31.noarch Conflicting name type transition rules Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1784 Failed to generate binary semodule: Failed! .... Can't issue 'selinux -DB' either..... semodule -DB Conflicting name type transition rules Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1784 Failed to generate binary semodule: Failed! Logged in to fresh install of Fedora 31 and hit this upon running the initial package update. Here is what dnf returned: Running scriptlet: selinux-policy-targeted-3.14.4-48.fc31.noarch 235/652 Conflicting name type transition rules Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1784 Failed to generate binary /usr/sbin/semodule: Failed! Resolved my issue with: dnf install container-selinux Running transaction Preparing : 1/1 Running scriptlet: container-selinux-2:2.124.0-3.fc31.noarch 1/1 Installing : container-selinux-2:2.124.0-3.fc31.noarch 1/1 Running scriptlet: container-selinux-2:2.124.0-3.fc31.noarch 1/1 libsepol.context_from_record: type stratisd_data_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:stratisd_data_t:s0 to sid invalid context system_u:object_r:stratisd_data_t:s0 Verifying : container-selinux-2:2.124.0-3.fc31.noarch 1/1 Installed: container-selinux-2:2.124.0-3.fc31.noarch Apparently this scriptlet managed to fix the issue. This looks like you have a bad policy module stratisd_data_t definition? perhaps something in file context definition. This is not related to container-selinux package. The issue should be fixed in all supported Fedoras with packages updated. If it still does not work for you, feel free to reopen this bz or create a new one and attach the following information: rpm -qa "selinux-policy*" "*-selinux" semodule -lfull|grep container ls -l /var/lib/selinux/targeted/active/modules/200/container/ I just saw this issue during today's F32 update, selinux-policy-targeted-3.14.5-32.fc32.noarch to selinux-policy-targeted-3.14.5-38.fc32.noarch: Conflicting name type transition rules Binary policy creation failed at /var/lib/selinux/targeted/tmp/modules/200/container/cil:1784 Failed to generate binary /usr/sbin/semodule: Failed! $ rpm -qa "selinux-policy*" "*-selinux" selinux-policy-3.14.5-38.fc32.noarch flatpak-selinux-1.6.3-1.fc32.noarch selinux-policy-targeted-3.14.5-38.fc32.noarch rpm-plugin-selinux-4.15.1-2.fc32.1.x86_64 $ sudo semodule -lfull|grep container [sudo] hasło użytkownika julas: 200 container pp $ sudo ls -l /var/lib/selinux/targeted/active/modules/200/container/ razem 44 -rw-------. 1 root root 12359 12-11 07:40 cil -rw-------. 1 root root 23083 12-11 07:40 hll -rw-------. 1 root root 2 12-11 07:40 lang_ext Julian,
I suppose you previous had container-seliunx installed. Some previous versions did not uninstall the module correctly on the package uninstall, it should be fixed with:
/usr/sbin/semodule -X 200 -s $targeted -r container
Thank you, I ran the command. I will report back if this helped once the next selinux update arrives. Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 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. |