From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051018 Fedora/1.7.12-2 Description of problem: Discussions have related about problems with post and pre script failures. I am having problems which related to this problem also. Some severe problems, like the system not being bootable because there was no policy.20 created have also been reported. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. run yum to update programs on system 2. get failures for several packages since pre scripts failed. 3. try to install cached yum rpm with rpm -Uvh 4. Get same script failure as described 3. Boot the system with selinux=0 4. change to yum cache (as root user) 5.try to install same rpm from yum cached rpms Actual Results: With selinux active, pre script failures never installed downloaded rpms which met deps according to yum or rpm. With SELinux off, rpms installed without failure Expected Results: The packages should have installed without problems. Additional info: This problem is causing post install scripts leaving entries for the old packages when the newer rpm programs are installed. This problem is also causing bailing out from downloaded rpms which never install.
from testing with and without selinux enabled. SELINUX enforcing: > Downloading Packages: > (1/1): selinux-policy-tar 100% |=========================| 221 kB 00:00 > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > error: %pre(selinux-policy-targeted-2.1.1-1.noarch) scriptlet failed, exit status 255 > error: install: %pre scriptlet failed (2), skipping selinux-policy-targeted-2.1.1-1 > > Updated: selinux-policy-targeted.noarch 0:2.1.1-1 > Complete! > [root@cornette-lt ~]# rpm -q selinux-policy-targeted > selinux-policy-targeted-2.1.0-1 > [root@cornette-lt ~]# cd /var/cache/yum/development/packages/ > [root@cornette-lt packages]# ls > selinux-policy-targeted-2.1.1-1.noarch.rpm > [root@cornette-lt packages]# rpm -Uvh sel*.rpm > Preparing... ########################################### [100%] > error: %pre(selinux-policy-targeted-2.1.1-1.noarch) scriptlet failed, exit status 255 > error: install: %pre scriptlet failed (2), skipping selinux-policy-targeted-2.1.1-1 > SELINUX disabled: ls selinux-policy-targeted-2.1.1-1.noarch.rpm [root@cornette-lt packages]# rpm -Uvh sel*.rpm Preparing... ########################################### [100%] 1:selinux-policy-targeted########################################### [100%] [root@cornette-lt packages]# rpm -q selinux-policy-targeted selinux-policy-targeted-2.1.1-1 [root@cornette-lt packages]# rpm -q --verify selinux-policy-targeted
I queried the rpm database and found duplicates of many packages. I feel that these were left in a bad state due to scripting errors triggered by security policies. A listing of rpms will be in an attached file.
Created attachment 122119 [details] These rpms were duplicates of previous installed rpms There were other rpms where I had to remove with the noscripts option to rpm. These are not on the listing. They were mainly java related packages.
When you turn selinux back on and relable are you seeing the same rpm behavior?
Using the policy installation as an example, I have the below output after relabeling the system, removing the db entries for the duplicated rpms. No packages now are downloaded but not installed. --verify does show the below output. rpm -qa |grep selinux libselinux-1.29.1-2 libselinux-devel-1.29.1-2 libselinux-python-1.29.1-2 selinux-policy-targeted-2.1.4-1 [root@cornette-lt ~]# [root@cornette-lt ~]# rpm -qV selinux-policy-targeted-2.1.4-1 ........C /etc/selinux/targeted/modules/active ........C c /etc/selinux/targeted/modules/active/seusers I'll check the system for fallout from lefover db entries lingering after the upgrading is completed and report back.
No duplicate packages were found within the rpmdb other than kernel and repository keys. No updates other than pcmciautils.i386 007-1.1 available for install but not updatable. (openoffice removed along with other log term dep problem apps) rpm -qaV >/home/rpm-verify prelink: /usr/lib/libavcodec-CVS.so: Could not parse `/usr/lib/libavcodec-CVS.so: error while loading shared libraries: libxvidcore.so.4: cannot enable executable stack as shared object requires: Permission denied' prelink: /usr/lib/libavformat-CVS.so: Could not parse `/usr/lib/libavformat-CVS.so: error while loading shared libraries: libmp3lame.so.0: cannot enable executable stack as shared object requires: Permission denied' prelink: /usr/lib/libpostproc.so.0.0.1.#prelink#.a7ZrbE Could not trace symbol resolving cat rpm-verify S.?...... /usr/lib/libavcodec-CVS.so S.?...... /usr/lib/libavformat-CVS.so S.?...... /usr/lib/libpostproc.so.0.0.1 S.5....T. c /etc/aliases I believe the problem is not showing up at present. # cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=enforcing # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0
Try restorecon -R -v /usr/lib
After running restorecon as in comment #7 rpm -qaV spits out the following output. cat /home/rpm-restorecon S.?...... /usr/lib/libavcodec-CVS.so S.?...... /usr/lib/libavformat-CVS.so ....L...C /usr/lib/libpostproc.so.0 S.?...... /usr/lib/libpostproc.so.0.0.1 S.?...... /usr/bin/enca S.5....T. c /etc/aliases S.?...... /usr/bin/mc ........C /usr/bin/latex ........C /usr/bin/pdflatex S.5....T. /usr/share/texmf-var/web2c/latex.fmt S.5....T. /usr/share/texmf-var/web2c/pdflatex.fmt
Another incident for exit code and multipackages. Running Transaction Updating : lirc ######################### [1/4] error: %post(lirc-0.8.0-0.2.pre2.fc5.i386) scriptlet failed, exit status 255 Updating : SDL_ttf ######################### [2/4] Cleanup : SDL_ttf ######################### [3/4] Updated: SDL_ttf.i386 0:2.0.7-3.fc5 lirc.i386 0:0.8.0-0.2.pre2.fc5 Complete! ]# rpm -q lirc lirc-0.8.0-0.2.pre1.fc5 lirc-0.8.0-0.2.pre2.fc5
What version of policy is this? How long since you last rebooted? What does id -Z return before you run rpm? I had this problem earlier, caused by login-related issues with the users/seusers file - something to do with running an non-MLS enabled policy with MLS-enabled files, but I don't remember the details.
I'm seeing this too, fully up2date rawhide, running the latest kernel after a fresh boot with "autorelabel" on the kernel cmd line to just make sure. Any rpm with script causes an "scriptlet failed, exit status 255" message no matter if I install it through ymu or directly with rpm. Depending on how I become root this works or not: -direct log in as root on console, no problem -log into gdm as normal user then su or "su -" from xterm fails -login as normal user on console then su or "su -" works fine for my fully up2date home x86_64 system, but I believe to remember that on my i386 rawhide system at work this scenario fails though. id -Z after "su -" from xterm: [root@shalem ~]# id -Z user_u:system_r:xdm_t:SystemLow-SystemHigh id -Z directly logged in on console: [root@shalem ~]# id -Z root:system_r:unconfined_t:SystemLow-SystemHigh and for reference id -Z after "su -" from normal user on console: [root@shalem ~]# id -Z user_u:system_r:unconfined_t:SystemLow-SystemHigh
xdm_t is the wrong context. What policy are you running. rpm -q selinux-policy-targeted
Hmm, [hans@shalem devel]$ rpm -q selinux-policy-targeted package selinux-policy-targeted is not installed [hans@shalem devel]$ rpm -qf /etc/selinux/targeted/setrans.conf file /etc/selinux/targeted/setrans.conf is not owned by any package [hans@shalem devel]$ rpm -qf /etc/selinux/targeted/contexts/default_type file /etc/selinux/targeted/contexts/default_type is not owned by any package Dunno how that happened, doing a yum -y install selinux-policy-targeted as we speak, once the relabel is done I'll mv all the rpmnew files just created over the old ones, reboot with autorelabel and report back.
Installing the latest version and then relabeling seems to have fixed things, id -Z after su - from an xterm now gives: [root@shalem ~]# id -Z user_u:system_r:unconfined_t:SystemLow-SystemHigh
The bad libsetrans from earlier in the week probably caused this. So I am going to close this bug