Comment 14 for bug 50971

Okay, things appear to be slightly more complicated. Here's an excerpt of the processes running when the bug appears.

 5555 ? S 0:00 \_ kdesu -u root -c adept_manager
 5558 pts/1 Ss+ 0:00 | \_ /usr/bin/kdesu_stub -
 5561 pts/2 Ts+ 0:00 | \_ /usr/bin/sudo -u root /usr/bin/kdesu_stub -

Since sudo performs an exec() and thus gets out of the way once it has succeeded, this means that kdesu has run sudo twice. The first time appears to be due to the call of checkNeedPassword() at kdebase/kdesu/kdesu/kdesu.cpp:338. This is the instance on pseudo terminal pts/1, which probably caused kdesu to think that it needed no password (see my explanation in the previous post). This explains why kdesu does not show the password prompt.

The second time is the real sudo attempt. However, because - for some reason - the kdesu_stub from the first attempt is still hanging around, the second sudo is started on the second pseudo terminal. Therefore, this second sudo attempt does require a password and therefore hangs during sudo.

Now the code in ConverseSU() in kdelibs/kdesu/su.cpp looks like it should take care of that problem, but apparently it doesn't. The effect is that according to backtraces, the kdesu process is already in ConverseStub(), while the sudo child process is still waiting for a password.

So it looks like there are two problems in the code, which together cause this bug:

1) Kdesu uses checkNeedPassword(), but this function is fundamently unable to predict whether the next sudo attempt will prompt for a password or not. The code as it currently stands is inherently racy and makes assumptions that are fundamentally ***wrong***.

2) Some problem in ConverseSU() or the surrounding code causes us to miss the fact that sudo is still waiting for a password.