Bug 173094 - Random rpm script failures (exit status 255)
Random rpm script failures (exit status 255)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libselinux (Show other bugs)
rawhide
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-13 21:16 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-26 20:40:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
avc errors before logs rotated (1.20 KB, text/plain)
2005-11-14 21:26 EST, Jim Cornette
no flags Details
avc errors in rotated log. (8.15 KB, text/plain)
2005-11-14 21:28 EST, Jim Cornette
no flags Details
libselinux.rpm_respect_mode.diff (790 bytes, patch)
2005-11-15 00:15 EST, Ivan Gyurdiev
no flags Details | Diff

  None (edit)
Description Ivan Gyurdiev 2005-11-13 21:16:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051103 Fedora/1.5-0.5.0.rc1 Firefox/1.5

Description of problem:
I am seeing random rpm script failures with exit status 255.

The scripts vary from /sbin/ldconfig to complex scripts. 80% of all rpms being installed fail in one way or another - I see %post, %pre, %trigger, %postun, %preun scripts failing. This is starting to drive me crazy, because things like the fontconfig %post script not executing cause every login/graphical program linked to the fonts library to crash. There's very severe consequences to installing packages when the scripts aren't working.

For example, the rpm %pre script fails, the openssl update proceeds... end result: rpm can no longer link to libssl.so.5, and my rpm command does not work.     

I've been seeing this bug for at least 1.5-2 weeks - haven't reported it yet, since I've been busy, and it might be specific to my machine.. but if it isn't, then it should block FC5.

================================================

Any ideas?

Version-Release number of selected component (if applicable):
rpm-4.4.2-7

How reproducible:
Always

Steps to Reproduce:
1. Install various rpms that use scripts
2. Scripts fail with status 255
  

Additional info:
Comment 1 Jeff Johnson 2005-11-13 21:54:40 EST
Well, the code in rpm-4.4.2-7 has not changed a whit in the last 1.5 to 2 weeks,
that's a Great Big Hint that this is a problem with your machine, or other software,
not rpm.
Comment 2 Jeff Johnson 2005-11-13 21:55:22 EST
Well, the code in rpm-4.4.2-7 has not changed a whit in the last 1.5 to 2 weeks,
that's a Great Big Hint that this is a problem with your machine, or other software,
not rpm.
Comment 3 Ivan Gyurdiev 2005-11-13 22:19:04 EST
A "problem with my machine" is usually a software bug that nobody has ran into
yet, but I have. I find it strange that the exit code of all these scripts is
255 - why?

I have a ton of rpms installed (all of core, all of extras, all of livna, and
more on top of that). Is that relevant? 

I run SELinux in permissive mode... 
Comment 4 John Ellson 2005-11-14 10:42:01 EST
Strange.  I saw a lot of the 255 error codes recently, just as you describe, but
I was sure that it was only on machines that were in enforcing mode.

Whay I did was to set them to permissive.  Reboot, clean up the rpms, run
"fixfiles relabel", set back to enforcing, reboot.   I haven't seen any more of
the "255" messages in the last three days of updates.
Comment 5 Jim Cornette 2005-11-14 15:36:41 EST
I relabeled my system and was still having trouble with the scriplets problem. 
There was a large list of rpms that would download via rpm and fail because of 
a scriplet problem. Since other packages were pulled in and yum expected the 
deps to be met, some packages were successfully upgraded while rpm (or yum) 
exited the script. This left older versions of rpm, xorg-x11-xfs and an 
assortment of other programs behind. Rpm would not function since it was 
actually never updated when openssl was updated. rpm wanted so.5 version 
liblraries and openssl provided so.6 versions. Of course rpm complained about 
the shared library not being available.

I'll add the listing of rpms that downloaded and never installed later when 
I'm at the computer that the scriplets failed on.
Comment 6 Ivan Gyurdiev 2005-11-14 15:56:16 EST
The ones that don't install are the ones that fail the %pre script. If the %post
fails, or the %postun of the old package, then rpm proceeds to install the
package. If the %postun fails, you get two packages in the database for the same
thing (I use rpm --e --justdb to fix).

I actually used rpm to upgrade things, but if you used yum, then this shows a
flaw in the transaction system - I would think a failed install of any rpm
should abort the whole transaction.

To recover your system link .so.6 as .so.5 and lie to rpm.
Comment 7 James Olin Oden 2005-11-14 16:49:02 EST
No thats not how it works.  RPM by default uses a best effort strategy for 
running transactions (provided all pre transaction checks pass, such as dep 
resolution, disk space utilization, etc.).   In the case of an installer like 
anaconda, and in many environments (though not in mine) this is the sanest 
policy, because you will likely still end up with a runable system though one 
package fails to install (or a few, and it depends on which one).

There is work to provide for automatic rollbacks of failed transactions, but 
this is experimental code at the moment.  Obviously another possible policy is 
to be able to have the transaction just halt, but no code as yet has been put 
in to allow for this experimental or otherwise.   Write an RFE if you would 
like to see said functionality.

Cheers...james
Comment 8 Ivan Gyurdiev 2005-11-14 17:01:29 EST
I'm not sure whether it makes sense to use "best effort" and "transaction" in
the same sentence. Isn't the point of a transaction to ensure atomic commit (to
whatever degree is possible), and to prevent the disaster that is happening here.

The system would be in good state either by not upgrading anything, or by
upgrading everything. Doing a partial upgrade just leaves it in corrupted state.
Whether it's "runnable" or not after that is uncertain. I guess I would like to
see this functionality, but that's not what this bug is about.
Comment 9 Jeff Johnson 2005-11-14 17:49:38 EST
Comment #4 seems to indicate an SELinux problem (libselinux, not rpm, does
scriptlet execs). Reassigning ...
Comment 10 Ivan Gyurdiev 2005-11-14 18:09:45 EST
Hm... I agree that this is the likely cause - I do not see rpm_execcon doing a
mode check. The function can cause a failure even in permissive mode, which is a
bug. I am also wondering why this function exists in a shared library in the
first place... 

My selinux setup is in complete chaos, since I work on libsemanage/libsepol, so
I'm sure something probably fails... have found lots of bugs that way :)
Comment 11 Jim Cornette 2005-11-14 21:24:07 EST
I have failures from both multiple entries for old and new packages. The problem
with rpms downloading but not installing via yum was similar to failures
encountered when rpm was used to try to install packages in the yum cache that
did not show as being installed.

The packages which never installed were below. I'll attach the avc errors from
messages and messages.1 since SELinux libraries seem to be the culpret.


anaconda.i386                            10.89.12-1
anaconda-runtime.i386                    10.89.12-1
bind.i386                                24:9.3.1-21
binutils.i386                            2.16.91.0.3-1
classpathx-mail.noarch                   1.0-4jpp_3fc
classpathx-mail-javadoc.noarch           1.0-4jpp_3fc
cpp.i386                                 4.0.2-6
ddd.i386                                 3.3.11-4
dovecot.i386                             0.99.14-10.fc5
dvgrab.i386                              2.0-1
fedora-logos.noarch                      1.1.34-1
freeradius.i386                          1.0.4-5
freeradius-mysql.i386                    1.0.4-5
freeradius-postgresql.i386               1.0.4-5
freeradius-unixODBC.i386                 1.0.4-5
gcc.i386                                 4.0.2-6
gcc-c++.i386                             4.0.2-6
gcc-gfortran.i386                        4.0.2-6
gcc-gnat.i386                            4.0.2-6
gcc-java.i386                            4.0.2-6
gcc-objc.i386                            4.0.2-6
gkrellm-daemon.i386                      2.2.7-4
gnome-panel.i386                         2.12.1-5
gphoto2.i386                             2.1.6-6
gphoto2-devel.i386                       2.1.6-6
gtkhtml3.i386                            3.8.1-2
hal.i386                                 0.5.4.cvs20051111-1
hal-devel.i386                           0.5.4.cvs20051111-1
hal-gnome.i386                           0.5.4.cvs20051111-1
httpd.i386                               2.0.54-16
iproute.i386                             2.6.14-9
jwhois.i386                              3.2.3-3
kbd.i386                                 1.12-11
kernel.i686                              2.6.14-1.1663_FC5
kernel-devel.i686                        2.6.14-1.1663_FC5
kernel-doc.noarch                        2.6.14-1.1663_FC5
lftp.i386                                3.3.3-1
libavc1394.i386                          0.5.1-1
libavc1394-devel.i386                    0.5.1-1
libdbi.i386                              0.8.1-1
libdbi-dbd-mysql.i386                    0.8.1a-1
libdbi-dbd-pgsql.i386                    0.8.1a-1
libdbi-devel.i386                        0.8.1-1
libdbi-drivers.i386                      0.8.1a-1
libgcc.i386                              4.0.2-6
libgcj.i386                              4.0.2-6
libgcj-devel.i386                        4.0.2-6
libgcj-src.i386                          4.0.2-6
libgfortran.i386                         4.0.2-6
libgnat.i386                             4.0.2-6
libmudflap.i386                          4.0.2-6
libmudflap-devel.i386                    4.0.2-6
libobjc.i386                             4.0.2-6
libraw1394.i386                          1.2.0-2.fc5
libraw1394-devel.i386                    1.2.0-2.fc5
libsemanage.i386                         1.3.53-2
libstdc++.i386                           4.0.2-6
libstdc++-devel.i386                     4.0.2-6
libuser.i386                             0.54.2-1
libuser-devel.i386                       0.54.2-1
logrotate.i386                           3.7.3-1
mailman.i386                             3:2.1.6-2
mod_auth_mysql.i386                      1:2.9.0-2
mysql-server.i386                        5.0.15-2
ntp.i386                                 4.2.0.a.20050816-10
nut-cgi.i386                             2.0.2-4
nut-client.i386                          2.0.2-4
openhpi.i386                             2.2.1-1
openhpi-devel.i386                       2.2.1-1
openldap-servers.i386                    2.3.11-2
openssh-server.i386                      4.2p1-6
oprofile.i386                            0.9.1-3
oprofile-devel.i386                      0.9.1-3
pam_krb5.i386                            2.2.0-2
perl.i386                                3:5.8.7-0.7.fc5
perl-suidperl.i386                       3:5.8.7-0.7.fc5
policycoreutils.i386                     1.27.27-3
postfix.i386                             2:2.2.5-2.1
postfix-pflogsumm.i386                   2:2.2.5-2.1
postgresql.i386                          8.1.0-4
postgresql-contrib.i386                  8.1.0-4
postgresql-devel.i386                    8.1.0-4
postgresql-docs.i386                     8.1.0-4
postgresql-jdbc.i386                     8.1.0-4
postgresql-libs.i386                     8.1.0-4
postgresql-pl.i386                       8.1.0-4
postgresql-python.i386                   8.1.0-4
postgresql-server.i386                   8.1.0-4
postgresql-tcl.i386                      8.1.0-4
postgresql-test.i386                     8.1.0-4
pyparted.i386                            1.6.10-1
rpm.i386                                 4.4.2-7
sendmail.i386                            8.13.5-2
squid.i386                               7:2.5.STABLE12-1
tmpwatch.i386                            2.9.5-1
udev.i386                                075-1
xorg-x11-xfs.i386                        6.8.2-62
yum.noarch                               2.4.0-13
Comment 12 Jim Cornette 2005-11-14 21:26:09 EST
Created attachment 121042 [details]
avc errors before logs rotated

Only a few entries here.
Comment 13 Jim Cornette 2005-11-14 21:28:31 EST
Created attachment 121043 [details]
avc errors in rotated log. 

I have no audit.log on my system. These entries are from 
cat /var/log/messages.1 |grep avc
Comment 14 Ivan Gyurdiev 2005-11-15 00:13:49 EST
On my system, the root cause of the failure is setexeccon. It fails on
"root:staff_r:rpm_script_t," most likely because the role is wrong.

For some reason logging in as root does not set the role as sysadm_r like it
should - needs further investigation.

Otherwise... patch attached, and sent to nsa-list to make this work in
permissive mode.
Comment 15 Ivan Gyurdiev 2005-11-15 00:15:48 EST
Created attachment 121046 [details]
libselinux.rpm_respect_mode.diff

Patch to make rpm_execcon respect the enforcing mode.
In permissive mode, all selinux-related failures should be non-fatal, and we
should attempt execve anyway.
Comment 16 Ivan Gyurdiev 2005-11-15 01:21:04 EST
The failure to begin with is caused by invalid context for my user, which
cascades and causes a ton of problems - if the current context is wrong, the one
after su is not valid either. I think I need to reboot, and it will probably get
fixed (hopefully). 
Comment 17 Jim Cornette 2005-11-15 06:39:35 EST
I ran yum from a virtual terminal (initial login as root) when I encountered the
error before.
After running yum this morning, updates installed without scripting errors. The
problem trying to install the kernel is no longer happening and the latest
kernel installed without issues on this round.
I am using permissive mode, so this error should not have happened. Your patch
or a like one that prevents errors in permissive mode should be added to the
policy regardless.

Note You need to log in before you can comment on or make changes to this bug.