Bug 527528
Summary: | yumex-2.9.x dont update kernel correctly (postinstall scriptlet report errors) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Deji Akingunola <dakingun> |
Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 12 | CC: | awilliam, che666, cia.watson, dwalsh, flokip, mgrepl, simon.lewis, tim.lauridsen |
Target Milestone: | --- | Keywords: | CommonBugs, Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | https://fedoraproject.org/wiki/Common_F12_bugs#yumex-kernel-update | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-12-07 22:46:31 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: |
Description
Deji Akingunola
2009-10-06 19:29:51 UTC
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. *** |