Hide Forgot
Description of problem: selinux-policy-targeted is default SELinux policy type on RHEL8. If I change one line in config file "/etc/selinux/config" from *SELINUXTYPE=targeted* to *SELINUXTYPE=minimum* and then I try to install corresponding selinux-policy package with this type of policy (selinux-policy-minumum), I get: # dnf install selinux-policy-minimum Updating Subscription Management repositories. Unable to read consumer identity This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Last metadata expiration check: 0:02:30 ago on Thu 14 Feb 2019 09:50:29 AM CET. Dependencies resolved. ========================================================================================================= Package Arch Version Repository Size ========================================================================================================= Installing: selinux-policy-minimum noarch 3.14.1-59.el8 BaseOS 13 M Transaction Summary ========================================================================================================= Install 1 Package Total download size: 13 M Installed size: 33 M Is this ok [y/N]: y Downloading Packages: selinux-policy-minimum-3.14.1-59.el8.noarch.rpm 842 kB/s | 13 MB 00:15 --------------------------------------------------------------------------------------------------------- Total 842 kB/s | 13 MB 00:15 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Failed to obtain the transaction lock (logged in as: root). The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Could not run transaction. I know, that It doesn't need to make sense that I change some configuration in SELinux and after that I'm trying to install some packages related to this change, but it worked on RHEL7 with warning msg in yum: Downloading packages: selinux-policy-minimum-3.13.1-236.el7.noarch.rpm | 6.9 MB 00:00:04 Running transaction check Running transaction test Transaction test succeeded Running transaction warning: Failed to open SELinux handle. Installing : selinux-policy-minimum-3.13.1-236.el7.noarch 1/1 Verifying : selinux-policy-minimum-3.13.1-236.el7.noarch 1/1 Installed: selinux-policy-minimum.noarch 0:3.13.1-236.el7 Complete! It looks there is some implementation difference in dnf and yum. Fedora Rawhide/29 is also affected. Version-Release number of selected component (if applicable): dnf-4.0.9.2-1.el8.noarch How reproducible: Always Actual results: dnf is broken (unable to install any package in system) after type change in /etc/selinux/config. Expected results: It will be possible or at least there will be some meaningful error msg that dnf cannot open SELinux handle and admin should fix it. Additional info: I'm part of SELinux team and we can help you with this bug, however I'm not sure whats happening under the dnf hood.
Um, Lukas: this is exactly the same thing as bug 1641631, it's just that dnf masks the more detailed error coming from rpm. See but https://bugzilla.redhat.com/show_bug.cgi?id=1641631#c16 in particular. Here you're just creating the same mismatch in different order, results in selinux_file_context_path() returning a path to non-existent file. The only thing that dnf is guilty of here is the misleading error message.
Please can we get some additional information from RPM for the issue or did you only suggest to improve error messages? Any example is welcome.
The problem here is that rpm logs a more detailed error message [*] but dnf swallows it. Very similar to what happens in bug 1658292 - the overall theme is that dnf is a bit too eager to hide away anything coming from rpm level. There are any number of things that can go wrong here, obtaining the transaction lock is just one of them. Dnf shouldn't go guessing what rpm is trying to do here and just let those errors through. [*] The rpm message in question from the selinux plugin is not that great in this situation either, but it does at least hint at selinux as the culprit. I improved it upstream and we need to get it into rhel-8 rpm, but that's not of much use as long as dnf masks it.
PR: https://github.com/rpm-software-management/dnf/pull/1430
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:3583