Description of problem: kdesu ges a segfault Version-Release number of selected component (if applicable): kdebase-3.5.1-2.2 How reproducible: 100% Steps to Reproduce: 1. Run `kdesu date' from a shell Actual results: segfault `strace -f -o log kdesu date' says: 3133 open("/dev/pts/11", O_RDWR) = 0 3133 close(10) = 0 3133 ioctl(0, TIOCSCTTY) = 0 3133 dup2(0, 0) = 0 3133 dup2(0, 1) = 1 3133 dup2(0, 2) = 2 3133 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 3133 ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 -opost isig icanon echo ...}) = 0 3133 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost isig icanon echo ...}) = 0 3133 execve("/bin/su", ["/bin/su", "root", "-c", "/usr/bin/kdesu_stub", "-"], [/* 58 vars */]) = 0 3133 +++ killed by SIGKILL +++ 3131 <... read resumed> 0xbfebe228, 255) = -1 EIO (Input/output error) 3131 --- SIGCHLD (Child exited) @ 0 (0) --- 3131 write(6, "\0", 1) = 1
These bugs are being closed since a large number of updates have been released after the FC5 test1 and test2 releases. Kindly update your system by running yum update as root user or try out the third and final test version of FC5 being released in a short while and verify if the bugs are still present on the system .Reopen or file new bug reports as appropriate after confirming the presence of this issue. Thanks
I did a `yum upgrade' 24 hours ago. That's what caused the error.
strange, i have updated my system to current rawhide, it works fine for me. It would be nice if you could do 'yum update' and try again. Thanks
I just did that - everthing was already up to date. kdesu still fails in the same manner. Booting 2.6.16-rc4-mm1 with `selinux=0' fixes the problem. 2.6.16-rc4-mm1 without `selinux=0' has the same problem. Also, there's an initscript bug. When I rebooted back into 2.6.16-rc4-mm1 without `selinux=0' it did that filesystem fixup thingy, then it didn't reboot (I expected it to?) and then we got an error here, in rc.sysinit:74 echo $SELINUX > $selinuxfs/enforce That write failed - I forget what the message was, though. So methinks we have an SELinux problem.. (kdesu fails in the same way with kernel 2.6.15-1.1955_FC5, btw) kdesu is part of kdebase-3.5.1-2.2
Do you have a fully labeled machine? Do you see avc messages? Can you turn SELinux on but in permissive mode and see if it works. Dan
> Do you have a fully labeled machine? What does this mean? It's a stock, up-to-date fc5-test1 install. I was running non-SELinux kernels for a while, but it's been reenabled for a while. And that relabelling pass which happens when I reboot into a stock RH kernel appears to do the right thing. > Do you see avc messages? Yes, I see a pile of those late in boot. > Can you turn SELinux on but in permissive mode and see if it works. sony:/home/akpm# echo 0 > /selinux/enforce <kdesu works> sony:/home/akpm# echo 1 > /selinux/enforce <kdesu fails>
touch /.autorelabel reboot You should not be seeing avc messages on boot. This sounds like a labeling problem
The messages to which I refer are simply "SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts". Nothing out of the ordinary. > touch /.autorelabel > reboot Did that. The relabelling ran OK. Once the kernel (2.6.15-1.1955_FC5) was fully booted, selinux was for some reason not in "enforce" mode. Which is odd, because normally it comes up in enforcing mode. So of course kdesu works OK. After doing echo 1 > /selinux/enforce kdesu again fails, in the same manner.
SELinux will be in the mode specified in /etc/selinux/config Ok, which AVC messages are you seeing in /var/log/audit/audit.log or /var/log/messages? BTW setenforce [1|0] does the same thing your echo script does.
> SELinux will be in the mode specified in /etc/selinux/config SELINUX=enforcing > Ok, which AVC messages are you seeing in /var/log/audit/audit.log > or /var/log/messages? Only one message type, it seems. Zillions of these: type=AVC msg=audit(1140638440.280:208): avc: denied { execstack } for pid=5666 comm="kdesktop_lock" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0 tclass=process
Ok, that indicates a fairly significant security problem in kde. http://people.redhat.com/drepper/selinux-mem.html You can work around this by setting the boolean setsebool -P allow_execstack=1
> setsebool -P allow_execstack=1 That didn't help (note that the above trace was from kdesktop_lock, not from kdesu). Different bug ;) It seems that I lied. Here's the audit log from an unsuccessful kdesu run: type=SYSCALL msg=audit(1140641185.506:898): arch=40000003 syscall=4 success=yes exit=2 a0=4 a1=bf958bf6 a2=2 a3=bf958bf8 items=0 pid=6450 auid=1107 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="setsebool" exe="/usr/sbin/setsebool" subj=user_u:system_r:unconfined_t:s0 type=AVC msg=audit(1140641190.063:899): avc: denied { sigkill } for pid=6453 comm="kdesu" scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1140641190.063:899): arch=40000003 syscall=37 success=no exit=-13 a0=1937 a1=9 a2=4327d818 a3=1 items=0 pid=6453 auid=1107 uid=1107 gid=1107 euid=1107 suid=1107 fsuid=1107 egid=1107 sgid=1107 fsgid=1107 tty=pts9 comm="kdesu" exe="/usr/bin/kdesu" subj=user_u:system_r:unconfined_t:s0 type=USER_AUTH msg=audit(1140641192.464:900): user pid=6455 uid=1107 auid=1107 msg='PAM: authentication acct=root : exe="/bin/su" (hostname=?, addr=?, terminal=pts/11 res=failed)'
If you do a chcon -t su_exec_t /bin/kdesu Does it work?
yup, chcon -t su_exec_t /usr/bin/kdesu fixes it. What would have caused this? Maybe a `yum upgrade' with SELinux disabled? But the RPM installer would only need xattrs?
Seems to be correct in the current policy. And a fresh install of kdebase seems to set up the correct label. Time to close this?
Yes, it's working OK with selinux-policy-2.2.23-6 - close it.