Red Hat Bugzilla – Bug 185594
rpm and/or up2date not installing some packages with %pre or %post scriptlets and selinux enabled
Last modified: 2007-11-30 17:07:24 EST
Description of problem: This happened when I was running up2date on my system. After downloading and updating most of the new packages present in RHEL ES 4 U3, up2date finished with some errors. Running up2date again, just to verify, showed that several packages were indeed not installed. After several more attempts with up2date, I downloaded some of the packages from RHN and tried to install them individually using rpm, but this failed, too. I found this RH mailing list thread where they mention almost the same problem. https://www.redhat.com/archives/redhat-list/2005-October/msg00281.html and state that if selinux was disabled, up2date and/or rpm should work as expected. Steps to Reproduce: 1) run up2date to update to download and install new packages. 2) run rpm to install packages Actual Results: Both up2date and rpm failed to install some packages (selinux was enabled, permissive mode). See attached file for details (for the sake of brevity, I illustrated the case with one package: diskdumputils). Expected Results: Both up2date and rpm shuld have been able to install these packages with selinux enabled. Additional info: I enabled selinux some time AFTER the system's initial installation. Maybe this is not an issue with systems installed with selinux enabled from the start.
Created attachment 126180 [details] CLI output from up2date and rpm commands
Where there any related avc messages? If you are a Red Hat Enterprise Linux customer and have an active support entitlement, you should also log the call with support, to be properly tracked. See the https://bugzilla.redhat.com/ homepage for more details.
No avc messages at all.
I recently had a very similar issue, up2date would not install updates and rpm would not install or remove anything unless the --noscripts flag was set. SELinux was disabled in /etc/selinux/config but the problem persisted. I finally narrowed the problem down to a kernel option, enforcing=0 in my grub.conf. After removing this all is well again. Hope someone can use this info because I was banging my head for a day or so to figure it out.
If "enforcing=0" in grub.conf fixed a problem, then the up2date/rpm failure was due to SELinux, probably bad policy.
Without avc errors we can't really diagnose this. If you enabled selinux post install you would have needed to do a full relabel and reboot. Closing. If you have additional information to add to this bug please reopen and update.
Bizarre... I can confirm the exact same behaviour in RHEL4.4, and also in CentOS 4.4 (for what that's worth). Don't have a current support contract for RHEL, so can't open a ticket there. Even weirder - on the CentOS system, I have 7 boxes that are *exact* clones of each other (i.e. used disk duplication, same IBM server hardware). One of them is on production, the other 6 are sitting idle. Only *ONE* of them (an idle system!) is having these problems. Spontaneously. One thing did happen differently on this system, now that I think about it - I used tar(1) to re-copy a bunch of files (I was testing some automation scripts) in the root filesystem. The RHEL4 system has had all sorts of things happen to it over time, and I would expect that selinux labels could very well be not 100% correct (it's a test box). Does GNU tar, as shipped, understand SELinux labels? And, more importantly, why would that matter with SELinux disabled??? Is this really an RPM bug, a tar bug, an selinux bug, or something else altogether? ... I've just tried relabeling the CentOS box, that didn't change anything. (Of course, with SELinux disabled, it shouldn't!)
(adding myself to CC list)