Bug 527528 - yumex-2.9.x dont update kernel correctly (postinstall scriptlet report errors)
Summary: yumex-2.9.x dont update kernel correctly (postinstall scriptlet report errors)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 523644 541759 543644 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-06 19:29 UTC by Deji Akingunola
Modified: 2009-12-07 22:46 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-07 22:46:31 UTC
Type: ---


Attachments (Terms of Use)

Description Deji Akingunola 2009-10-06 19:29:51 UTC
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:

Comment 1 Tim Lauridsen 2009-10-07 12:15:33 UTC
Thanks for reporting, I will try to reproduce the issue and find the cause

Comment 2 Deji Akingunola 2009-10-24 17:42:50 UTC
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.

Comment 3 Cia Watson 2009-10-27 04:49:41 UTC
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

Comment 4 Tim Lauridsen 2009-10-27 09:44:39 UTC
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.

Comment 5 Tim Lauridsen 2009-10-27 17:43:28 UTC
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 :)

Comment 6 Tim Lauridsen 2009-10-28 08:01:08 UTC
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

Comment 7 Tim Lauridsen 2009-10-28 08:05:12 UTC
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

Comment 8 Tim Lauridsen 2009-10-28 11:11:15 UTC
*** Bug 523644 has been marked as a duplicate of this bug. ***

Comment 9 Daniel Walsh 2009-10-28 12:40:58 UTC
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

Comment 10 Tim Lauridsen 2009-10-28 13:13:18 UTC
 (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 !

Comment 11 Tim Lauridsen 2009-10-28 14:03:06 UTC
Added Dan as CC, so he can see my reply :)

Comment 12 Daniel Walsh 2009-10-28 14:11:38 UTC
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  :^(

Comment 13 Tim Lauridsen 2009-10-29 06:08:25 UTC
(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  :^(  

:)

Comment 14 Bug Zapper 2009-11-16 13:20:24 UTC
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

Comment 15 Deji Akingunola 2009-12-01 22:29:05 UTC
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.

Comment 16 Daniel Walsh 2009-12-01 22:37:29 UTC
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

Comment 17 Panu Matilainen 2009-12-03 13:53:40 UTC
*** Bug 541759 has been marked as a duplicate of this bug. ***

Comment 18 Simon Lewis 2009-12-05 09:03:08 UTC
*** Bug 543644 has been marked as a duplicate of this bug. ***


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