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):
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.
Shouldn't infinite loop.
Perhaps after (for example) usernet closes, userhelper should also terminate.
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?
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.