Created attachment 376128 [details] Output of 'strace -e trace=process,ioctl,setpgid -f su root' Description of problem: When calling "su root" the command hangs for about 25 seconds until one is asked for the password. CRTL+C terminates it immediately. After the delay 'su' functions normal. If one changes from root to a normal user (no password required) 'su' does not freeze. Version-Release number of selected component (if applicable): Name : coreutils Arch : x86_64 Version : 7.6 Release : 7.fc12 Size : 11 M Repo : installed From repo : updates-testing How reproducible: Always Steps to Reproduce: 1. Open a terminal 2. login as normal user 3. run 'su root' Actual results: 'su' hangs for about 25 seconds until it asks for a password Expected results: Should ask for password immediately Additional info: This behavior is new to me since today and probably related to a 'yum update' I did yesterday. I added the output of 'strace -e trace=process,ioctl,setpgid -f su root'. The freeze occurs after the secound 'ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0'.
Thanks for report, looks similar to https://bugzilla.redhat.com/show_bug.cgi?id=456808 or https://bugzilla.redhat.com/show_bug.cgi?id=543274 . Thanks for the strace...
Created attachment 376137 [details] Output of 'strace -f su root' The command freezes after line 419: poll([{fd=4, events=POLLIN}], 1, 24991) = 0 (Timeout).
Are you saying the update triggers it? Could you please attach the relevant part of /var/log/yum.log?
Please try the following command as root: # authconfig --disablefingerprint --update
Created attachment 376144 [details] yum.log (excerpt) I suppose the update is responsible, but I can't say for sure. (There is a minor mistake in my description: The update was today at lunch time.)
Ok, 'authconfig --disablefingerprint --update' did the trick.
Thanks for clarifying it! I blame this part of the update: Dec 04 12:12:52 Updated: libfprint-0.1.0-14.pre2.fc12.x86_64 Reassigning to libfprint for now.
It's an SELinux issue. Eric said: #============= fprintd_t ============== allow fprintd_t unconfined_t:dbus send_msg; #============= policykit_auth_t ============== allow policykit_auth_t fprintd_t:dbus send_msg;
I'm only trying to be a little bit rude, but can we instead claim it's a developer issue, since if they developed with SELinux turned on (as more than 90% of the users who reported smolt data for more than 3 months in F11 did) this would have been caught and fixed before it hit a repo? In any case, it appears to me that allowing this in SELinux policy does take care of the hang.
I can confirm that # audit2allow -i /var/log/audit/audit.log comes up with: #============= fprintd_t ============== allow fprintd_t unconfined_t:dbus send_msg; #============= policykit_auth_t ============== allow policykit_auth_t fprintd_t:dbus send_msg; After reenabling the bug with # authconfig --enablefingerprint --update' again the following lines fixed it: # audit2allow -M fingerprinters -l -i /var/log/audit/audit.log # semodule -i fingerprinters.pp
(In reply to comment #9) > I'm only trying to be a little bit rude, but can we instead claim it's a > developer issue Given that the update only adds a new driver to libfprint, and doesn't do anything else, I can be a bit rude as well and stop giving a monkey's :) It was probably broken before, just that nobody noticed... > , since if they developed with SELinux turned on (as more than > 90% of the users who reported smolt data for more than 3 months in F11 did) > this would have been caught and fixed before it hit a repo? > > In any case, it appears to me that allowing this in SELinux policy does take > care of the hang.
(In reply to comment #10) Patrick, thanks for digging this out! We were forced to close the same bug several times before because of lack of information. Eric, what's the plan to fix it? Include the rules in next update of selinux-policy?
reassigning to selinux policy.
Fixed in selinux-policy-3.6.32-55.fc12.noarch yum update selinux-policy-targeted --enablerepo=updatest-testing This was actually caused by me :^( There was a bug in policy that was allowing all dbus processes to send dbus messages to all unconfined domains. We removed this, since this allowed confiined users to send dbus messages to services like packagekit, which we want to prevent. But because of this we missed fprintd sending dbus messages to unconfined_t. allow policykit_auth_t fprintd_t:dbus send_msg; I have never seen this one before. I will add to 56. Also the release that caused the su hang never made it out of updates-testing. Please test 55 and make sure it fixes the problem.
(In reply to comment #14) > There was a bug in policy that was allowing all dbus processes to send dbus > messages to all unconfined domains. We removed this, since this allowed > confiined users to send dbus messages to services like packagekit, which we > want to prevent. But because of this we missed fprintd sending dbus messages > to unconfined_t. That explains a lot. I am able to reproduce the bug by updating to 54. When I update further to 55, the problem vanishes.
Please update the karma.
Done. FWIW here is a link to that update for others: https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12650
Revision 55 introduces bug 544787 .
Ok I will push and get out a test update for 544787. -56