Description of problem: I ve noticed that some rpm post-install scriplets do fail to run when I'm using yumex to install or upgrade some packages, but these installs fine with using yum on the commandline. In F-11 kernel install (as part of updates) usually fails when build initrds. I also just noticed that on current rawhide, updating initscript-8.99-1.x86_64 to initscript-9.00 fails with yumex, but succeeded when done directly by yum on the commandline. Version-Release number of selected component (if applicable): yumex-2.9.1-1.fc12.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Thanks for reporting, I will try to reproduce the issue and find the cause
Noticed it again today with the kernel update, here is a relevant small portion of the output window; ... 13:33:44 : Installed kernel-2.6.31.5-96.fc12.x86_64 13:33:46 : YUM: /sbin/new-kernel-pkg: line 292: /sbin/depmod: Permission denied 13:34:05 : YUM: /usr/bin/ldd: line 118: /sbin/udevd: Permission denied 13:34:11 : Updated sane-backends-libs-1.0.20-10.fc12.x86_64 13:34:13 : Updated sane-backends-1.0.20-10.fc12.x86_64 13:34:16 : Updated git-1.6.5.1-1.fc12.x86_64 13:34:19 : Updated perl-Git-1.6.5.1-1.fc12.noarch ... I think it might be due to the root authentication expiring before the transaction is finished.
I had the same issue, I removed the kernel via yumex and now I'm installing the update via terminal. My output had a little more to it, so I thought I'd add it here, in case it helps: 21:20:37 : Installed kernel-firmware-2.6.31.5-96.fc12.noarch 21:20:44 : Installed kernel-2.6.31.5-96.fc12.x86_64 21:20:45 : YUM: /sbin/new-kernel-pkg: line 292: /sbin/depmod: Permission denied 21:21:18 : YUM: /usr/bin/ldd: line 118: /sbin/udevd: Permission denied 21:21:18 : YUM: E: Failed to install /lib/libnss_files* 21:21:19 : YUM: mkinitrd failed 21:21:19 : YUM: Non-fatal POSTIN scriptlet failure in rpm package kernel-2.6.31.5-96.fc12.x86_64 21:21:19 : YUM: RPM Scriptlet: warning: %post(kernel-2.6.31.5-96.fc12.x86_64) scriptlet failed, exit status 1 21:21:21 : Transaction completed successfully
Yes, i hit it myself. the post install script in the kernel rpm are running the following cmd: /sbin/new-kernel-pkg --package kernel-PAE --mkinitrd --dracut --depmod --install 2.6.31.5-96.fc12.i686.PAE || exit $? I added a verbose flag by editing /sbin/new-kernel-pkg. and got this output: YUMEX (with verbose /sbin/new-kernel-pkg) ================================================== Installed kernel-PAE-2.6.31.5-96.fc12.i686 YUM: initrdfile is /boot/initramfs-2.6.31.5-96.fc12.i686.PAE.img YUM: making it the default based on config YUM: running depmod for 2.6.31.5-96.fc12.i686.PAE YUM: /sbin/new-kernel-pkg: line 292: /sbin/depmod: Permission denied YUM: creating initrd: /sbin/dracut -f /boot/initramfs-2.6.31.5-96.fc12.i686.PAE.img 2.6.31.5-96.fc12.i686.PAE YUM: /usr/bin/ldd: line 126: /sbin/udevd: Permission denied YUM: found /boot/initramfs-2.6.31.5-96.fc12.i686.PAE.img and using it with grubby YUM: adding 2.6.31.5-96.fc12.i686.PAE to /boot/grub/grub.conf YUM: /etc/lilo.conf does not exist, not running grubby YUM: initrdfile is /boot/initrd-2.6.31.5-96.fc12.i686.PAE.img the line there is failing is: (/sbin/new-kernel) depmod -ae -F /boot/System.map-$version $version where $version is the kernel version i tried adding some test code in the yumex yum backend (running as root) to do a os.system('/sbin/new-kernel-pkg --package kernel-PAE --mkinitrd --dracut --depmod --install 2.6.31.5-96.fc12.i686.PAE') and some code to trigger the test from the gui. this test was running without errors, so it only fail when running by rpm as a postinstall script. :( I will try to debug it a little deeper.
Ok, it look like I can reproduce it with this test yum-api script. 1. Boot latest kernel-1 2. remove latest kernel ( sudo rpm -e kernel-PAE-2.6.31.5-96.fc12.i686) 3. run 'sudo python test.py' test.py: import yum print "Staring" yb = yum.YumBase() yb.update(name='kernel-PAE') print "resove deps" rc,msgs = yb.buildTransaction() print rc,msgs if rc == 2: print "Running RPM Transaction" yb.processTransaction() print "Ended" OUTPUT: $ sudo python test.py .. .. initrdfile is /boot/initramfs-2.6.31.5-96.fc12.i686.PAE.img making it the default based on config running depmod for 2.6.31.5-96.fc12.i686.PAE /sbin/new-kernel-pkg: line 292: /sbin/depmod: Permission denied creating initrd: /sbin/dracut -f /boot/initramfs-2.6.31.5-96.fc12.i686.PAE.img 2.6.31.5-96.fc12.i686.PAE /usr/bin/ldd: line 126: /sbin/udevd: Permission denied found /boot/initramfs-2.6.31.5-96.fc12.i686.PAE.img and using it with grubby adding 2.6.31.5-96.fc12.i686.PAE to /boot/grub/grub.conf /etc/lilo.conf does not exist, not running grubby initrdfile is /boot/initrd-2.6.31.5-96.fc12.i686.PAE.img So the issue is inside the yum api. I will dig deeper :)
It is a SELinux issue running chcon system_u:object_r:rpm_exec_t:s0 /usr/share/yumex/yumex-yum-backend restorecon -r /usr/share/yumex as root fixes the issue
The current targeted policy is setting /usr/share/yumex/yumex to system_u:object_r:rpm_exec_t:s0 but in the current version of yumex it is /usr/share/yumex/yumex-yum-backend there is doing the yum/rpm action can it be added to the policy too for F11 and F12
*** Bug 523644 has been marked as a duplicate of this bug. ***
I am not crazy about giving this label to a shell script, and do not understand why you need the script in the first place. Why not just make /usr/share/yumex/yum_childtask.py be /usr/share/yumex/yumex-yum-backend? Can you add te -E to the /usr/share/yumex/yum_cildtask.py Can this app be separated into a dbus/Policykit application? I will change the labeling in selinux-policy-3.6.32-36.fc12.noarch
(In reply to comment #9) > I am not crazy about giving this label to a shell script, and do not understand > why you need the script in the first place. Why not just make > > /usr/share/yumex/yum_childtask.py be /usr/share/yumex/yumex-yum-backend? /usr/share/yumex/yumex-yum-backend i started by consolehelper (/usr/bin/yumex-yum-backend) it is spawned as a child process to the yumex gui (running as non root) Yes, /usr/share/yumex/yum_childtask.py could be linked to /usr/share/yumex/yumex-yum-backend?. The script is not strictly needed. i will do that in the next release. > > Can you add te -E to the /usr/share/yumex/yum_cildtask.py > I not sure what you mean here > Can this app be separated into a dbus/Policykit application? > Maybe, when Policykit is not a moving target and get some python binding but it is currently separated in a backend runnning as root doing all the yum/rpm actions (using consolehelper) and a gui part running as normal user. > I will change the labeling in selinux-policy-3.6.32-36.fc12.noarch Thanks a lot !
Added Dan as CC, so he can see my reply :)
Man python ... -E Ignore environment variables like PYTHONPATH and PYTHONHOME that modify the behavior of the interpreter. SELinux transition rules are somewhat like setuid programs. Labeling your backend as rpm_exec_t, allows it to pretty much read/write anywhere on the system. So it is fairly dangerous. Giving a script or a python program additional privs is potentially dangerous, so I like to be careful. If I am allowed to execute your script and can convince it to do something other then install yum repos, I have a security problem. The separation is good, and seems that you are fairly close to what the dbus/polickit would need. consolehelper is difficult to confine with SELinux. where dbus/policykit is somewhat easier. Sadly SELinux config tools still use consolehelper :^(
(In reply to comment #12) > Man python > ... > -E Ignore environment variables like PYTHONPATH and PYTHONHOME that > modify the behavior of the interpreter. > > > SELinux transition rules are somewhat like setuid programs. Labeling your > backend as rpm_exec_t, allows it to pretty much read/write anywhere on the > system. So it is fairly dangerous. Giving a script or a python program > additional privs is potentially dangerous, so I like to be careful. If I am > allowed to execute your script and can convince it to do something other then > install yum repos, I have a security problem. > i have added a '-E' to the python shebang http://git.fedoraproject.org/git/?p=yumex.git;a=commitdiff;h=3992933bfbc2624596a79ec14caa32a521393f8c > The separation is good, and seems that you are fairly close to what the > dbus/polickit would need. consolehelper is difficult to confine with SELinux. > where dbus/policykit is somewhat easier. Sadly SELinux config tools still use > consolehelper :^( :)
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I wonder what's left to finally fix this. I have yumex-2.9.4-1.fc12 and selinux-policy-3.6.32-46.fc12, but I still got post-install failure on updating a F12 system today. The failure didn't occur after I set SElinux to permissive and performed the failed update again with yumex.
chcon -t rpm_exec_t /usr/share/yumex/yum_childtask.py THen try to use yumex with SELinux in enforcing mode. This is going to be the default label. Fixed in selinux-policy-3.6.32-53.fc12.noarch
*** Bug 541759 has been marked as a duplicate of this bug. ***
*** Bug 543644 has been marked as a duplicate of this bug. ***