Bug 185594

Summary: rpm and/or up2date not installing some packages with %pre or %post scriptlets and selinux enabled
Product: Red Hat Enterprise Linux 4 Reporter: Marcelo Giles <mgiles>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED CANTFIX QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: athompso, herrold, nobody+pnasrat
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-08 22:21:23 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:
Attachments:
Description Flags
CLI output from up2date and rpm commands none

Description Marcelo Giles 2006-03-16 00:15:01 UTC
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.

Comment 1 Marcelo Giles 2006-03-16 00:15:01 UTC
Created attachment 126180 [details]
CLI output from up2date and rpm commands

Comment 2 Paul Nasrat 2006-03-16 15:45:42 UTC
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.

Comment 3 Marcelo Giles 2006-03-16 18:27:57 UTC
No avc messages at all.


Comment 4 Todd Weaver 2006-04-05 16:10:08 UTC
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.

Comment 5 Jeff Johnson 2006-08-08 04:55:57 UTC
If "enforcing=0" in grub.conf fixed a problem, then the up2date/rpm failure was due to SELinux,
probably bad policy.

Comment 6 Paul Nasrat 2006-08-08 22:21:23 UTC
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.

Comment 7 Adam Thompson 2007-03-05 02:16:28 UTC
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!)


Comment 8 Adam Thompson 2007-03-05 02:18:25 UTC
(adding myself to CC list)