Red Hat Bugzilla – Bug 62195
userhelper "Password:" Infinite Loop in console
Last modified: 2007-04-18 12:41:22 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0; Linux) Description of problem: In certain cases userhelper will go into an infinite loop. (without usermode-gtk package installed as was the default in Skipjack) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install "usermode" but not "usermode-gtk" package. 2. As non-root user, run "usernet" in a console. (I suspect any other program that users userhelper may also be effected.) 3. Right click usernet and select "Configure Network..." 4. Console will show "Password:" prompt. Close the usernet program. 5. Console will show bash prompt. Hit enter once and wait a second. 6. Infinite Loop of "Password:" filling the screen, unkillable by CTRL-C. Expected Results: Shouldn't infinite loop. Perhaps after (for example) usernet closes, userhelper should also terminate. Additional info: When usermode-gtk package is installed, a GUI window always pop-ups up asking for password rather than within the console. It doesn't terminate when the calling program is terminated. Is this expected behavior too?
This actually turns out to be a bug in libpam_misc, which will be fixed in pam-0.75-31 and later. Thanks!
Tested in Skipjack beta 2: userhelper no longer infinite loops, but it wont die when the calling program has been killed. The parent process changes to 1 (init) instead, and it co-exists with the console prompt. After a while it dies, but the console (at least in konsole) acts strangely. userhelper should be swiftly killed when the calling process has been killed rather than change its parent to init. Should I re-open this bug or post a new one? Also.... I've seen this strange behavior in the bash console that is the result of this userhelper terminating in other cases before and I suspect that THAT may be another seperate bug. I know two cases that triggers it, but I don't know how to describe it.
Hmm. The userhelper process is setuid, so the caller can't kill it, and because it's blocked reading from stdin, it can't notice that its parent's gone. Not sure how to fix this aside from making sure it doesn't happen.