kdesu will not start apps

[SteveG]

to reproduce: alt+F2 > kdesu konqueror > input sudoers password
no output is visible in the gui, although 'ps axu | grep kdesu' shows more processes starting each time kdesu is run. Below is the output of 'ps axu | grep kdesu' first before kdesu, then after 2 succeeding kdesu

steve@server4:~$ ps axu | grep kdesu
root 13187 0.0 0.0 1748 584 ? Ss 20:55 0:00 /usr/bin/kdesu_stub -
steve 13387 0.0 0.0 2884 816 pts/1 S+ 20:58 0:00 grep kdesu
steve@server4:~$ ps axu | grep kdesu
root 13187 0.0 0.0 1748 584 ? Ss 20:55 0:00 /usr/bin/kdesu_stub -
steve 13388 3.7 1.3 26232 13556 ? S 20:59 0:00 kdesu konqueror
steve 13390 0.0 0.2 16644 2696 ? S 20:59 0:00 /usr/bin/kdesud
root 13392 0.0 0.0 2472 980 pts/2 Ss+ 20:59 0:00 /usr/bin/sudo -u root /usr/bin/ kdesu_stub -
root 13396 0.0 0.0 1748 588 pts/3 Ss+ 20:59 0:00 /usr/bin/kdesu_stub -
steve 13402 0.0 0.0 2876 796 pts/1 R+ 20:59 0:00 grep kdesu
steve@server4:~$ ps axu | grep kdesu
root 13187 0.0 0.0 1748 584 ? Ss 20:55 0:00 /usr/bin/kdesu_stub -
steve 13388 0.2 1.3 26232 13556 ? S 20:59 0:00 kdesu konqueror
steve 13390 0.0 0.3 16644 3112 ? S 20:59 0:00 /usr/bin/kdesud
root 13392 0.0 0.0 2472 980 pts/2 Ss+ 20:59 0:00 /usr/bin/sudo -u root /usr/bin/ kdesu_stub -
root 13396 0.0 0.0 1748 588 pts/3 Ss+ 20:59 0:00 /usr/bin/kdesu_stub -
steve 13423 2.1 1.3 26240 13972 ? S 21:03 0:00 kdesu konqueror
root 13425 0.0 0.0 2468 980 pts/7 Ss+ 21:03 0:00 /usr/bin/sudo -u root /usr/bin/ kdesu_stub -
root 13439 0.0 0.0 1752 592 pts/8 Ss+ 21:04 0:00 /usr/bin/kdesu_stub -
steve 13444 0.0 0.0 2880 796 pts/1 R+ 21:04 0:00 grep kdesu
steve@server4:~$

[SteveG (steve-fpig)]

using kubuntu lts 6.06 with all updates;

[SteveG (steve-fpig)]

further trial and error shows that konqueror is the only app that will not open with kdesu. Other apps do open, eg kate, kcontrol, etc.

[Christmas (christmas)]

This happens to me on Kubuntu Dapper with all the updates. "kdesu konqueror" fails sometimes to open Konqueror in root mode. I also noticed this failure in some other applications, for example Adept fails to start sometimes. Sometimes it does, sometimes it doesn't.

[amichair (amichai2)]

I'm on Edgy, with the same problem, and not only in Konqueror. Also "kdesu Kate" and "K-Menu -> System Settings -> Administrator Mode" fail. I *think* this happens after using 'Administrator Mode' button in system settings - it works the first time, but sometimes after that it does not work a second time and neither do the other apps. A restart solves the problem.

[Paolo Sammicheli (xdatap1)]

Hi SteveG, hi everybody

Thanks for taking the time to report this bug.

May you confirm us if that bug can be reproduced on edgy with all update? I can't reproduce it

Thanks in advance

[amichair (amichai2)]

Well my previous comment was from 10 days ago, on an up to date Edgy, so unless something changed since then...

btw I don't remember it being deterministically reproducible - I haven't noticed any specific series of steps that would recreate this every time (though maybe I just didn't notice the steps involved). But it happened often enough to be noticeable (and annoying) ever since I first installed Dapper, and still happened as recent as two weeks ago.

As I mentioned, this mostly happened when I was tinkering around with the System Settings - opening and closing them, browsing and modifying various settings in various sections of the configuration, checking out different setting values, rebooting, etc. - basically exploring the whole system (being an experienced Windows user taking his first steps in Linux :-) )

[SteveG (steve-fpig)]

On Wed, 2006-12-13 at 16:29 +0000, Paolo Sammicheli wrote:
> Hi SteveG, hi everybody
>
> Thanks for taking the time to report this bug.
>
> May you confirm us if that bug can be reproduced on edgy with all
> update? I can't reproduce it
>
> Thanks in advance
>
>
> ** Changed in: kdebase (Ubuntu)
> Assignee: (unassigned) => Paolo Sammicheli
> Status: Unconfirmed => Needs Info
>

Greetings,

I just tested kdesu on edgy, and it seems to work.

Cheers, Steve G
--
Steve Glasser <email address hidden>

[Vosilij Pupkin (dammage)]

Clean kubuntu 6.10 install (+ devtools):
fails often.
Workaround: kill kdesud

Tried to reproduce it, but it is not deterministic. If you start a few apps (or the same app a few times) in a row, it fails. Sometimes it just fails on first start, once in a while it works flawlessly.

[Nicolai Hähnle (nha)]

This bug happened to me twice so far, but I cannot reproduce it reliably either.

My system: Kubuntu 6.10, recently updated.

It happened in the System Settings, trying to get into Admin Mode.

I installed kdelibs-dbg and kdebase-dbg and attached gdb to the kdesu process that seemed to hang. The kdesu command line was:

/usr/bin/kdesu --nonewdcop --n kcmshell System/userconfig --embed 41945746 --lang de

The backtrace was:

(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7a3fb43 in read () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7bd160a in PtyProcess::readLine (this=0xbfd58ff4, block=true)
    at /build/buildd/kdelibs-3.5.5/./kdesu/process.cpp:218
#3 0xb7bd61cd in StubProcess::ConverseStub (this=0xbfd58ff4, check=0)
    at /build/buildd/kdelibs-3.5.5/./kdesu/stub.cpp:85
#4 0xb7bd9194 in SuProcess::exec (this=0xbfd58ff4, password=0x0, check=0)
    at /build/buildd/kdelibs-3.5.5/./kdesu/su.cpp:198
#5 0x08050053 in main (argc=-1208796089, argv=0xbfd58b80) at /build/buildd/kdebase-3.5.5/./kdesu/kdesu/kdesu.cpp:422
#6 0xb79978cc in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#7 0x0804e001 in _start ()

I hope that helps.

[Nicolai Hähnle (nha)]

I got this bug again using an installation of Kubuntu Feisty Herd-2 with recent updates. Again I attached to the kdesu process, and the backtrace looks as in my comment just before this one.

This time, I also remembered to attach to the corresponding kdesu_stub and create a stacktrace:

(gdb) bt
#0 0xb7fcd410 in ?? ()
#1 0xbfa3ee94 in ?? ()
#2 0x00000400 in ?? ()
#3 0xb7fca000 in ?? ()
#4 0xb7f3ce93 in __read_nocancel () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7ede4d8 in _IO_file_read_internal () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7edf8a0 in _IO_new_file_underflow () from /lib/tls/i686/cmov/libc.so.6
#7 0xb7edff9b in _IO_default_uflow_internal () from /lib/tls/i686/cmov/libc.so.6
#8 0xb7ee12fd in __uflow () from /lib/tls/i686/cmov/libc.so.6
#9 0xb7ed5096 in _IO_getline_info_internal () from /lib/tls/i686/cmov/libc.so.6
#10 0xb7ed4fe1 in _IO_getline_internal () from /lib/tls/i686/cmov/libc.so.6
#11 0xb7ed3f8a in fgets () from /lib/tls/i686/cmov/libc.so.6
#12 0x08048ebf in main () at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kdesu/kdesu_stub.c:203
#13 0xb7e92ebc in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#14 0x08048bd1 in _start ()

Some shallow further "analysis":

(gdb) up
#12 0x08048ebf in main () at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kdesu/kdesu_stub.c:203
203 in /build/buildd/kdelibs-3.5.5a.dfsg.1/./kdesu/kdesu_stub.c
(gdb) print i
$4 = 0

It seems that not much at all happened during the communication.

If somebody can give any hints as to how I could help track down this bug, please do tell me.

[kko (kko)]

Could this be related to bug #72545 in some way?

[Nicolai Hähnle (nha)]

Definitely sounds like bug #72545 is could be a duplicate, but I couldn't say for certain. Whenever I suffered this bug, I was definitely working with Konsole as well, though I'm not certain whether I had invoked sudo manually.

I tried reproducing both this bug and bug #72545 per the given instruction right now, but no such "luck", i.e. I couldn't reproduce either of them. Unfortunately, this bug has always appeared to be quite non-deterministic.

[Nicolai Hähnle (nha)]

Okay, I take that back. I'm almost certain that bug #72545 is a duplicate.

The following steps reproduce the bug reliably for me:
1. Open Konsole
2. Do a sudo -k to get a clean slate
3. Run e.g. sudo ls (just some arbitrary, not too-complex command; sudo dmesg works as well)
4. exit (this should close Konsole)
5. Immediately launch Adept

No password dialog will appear, kdesu will hang.

Here's an explanation attempt (with my very limited knowledge about sudo):
Whenever you make a successful sudo attempt, sudo records that somewhere in order to save you from having to retype your password. Now sudo must somehow remember the context in which you made that successful attempt, so it stores the terminal that in ran on. In step 3, this happens to be some pseudo terminal.

In step 4, you close that pseudo terminal, but obviously sudo won't know that, so the record of the successful sudo attempt is still there.

In step 5, kdesu launches sudo, using a pseudo terminal for communication. It will just use the first available pseudo terminal, which happens to be the one that we just closed. Sudo will see the applicable record and thus not prompt for a password. Kdesu gets confused by that and hangs forever.

[Nicolai Hähnle (nha)]

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.

[kko (kko)]

N.B.: If this misbehaviour of kdesu is deemed to be caused by the same causes as that from bug #72545, which IMO seems quite likely, (and not due to some different cause,) there is some relevant information also in that report.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

Marking 72545 a dupe of this, and setting this to high importance.

Now that we know where the problem actually is, we're more likely to be able to fix this. (as opposed to it being random)

[Freddy Martinez (freddymartinez9)]

Hobbsee, this error seems to just be the application that has sudo privalages does not release these permissions (fast enough). Anyone want to try to tackle this one?

[Freddy Martinez (freddymartinez9)]

Also, I wonder if anyone can reproduce upstream. Thoughts.

[^rooker (rooker)]

Just wanted to add that I can reproduce this bug with Feisty (everything up-to-date, so I guess I'm running Herd 4?).

Here's how I can reproduce it:
- Open Konsole
- #kdesu kate
- Enter password
- Immediately after Kate opened, close it (click on close-icon in upper-right corner)
- #kdesu kate

#ps aux shows some stuck processes related to this:

myuser 7984 1.7 3.0 124812 15584 pts/2 S+ 21:20 0:00 kdesu kate
root 7987 0.0 0.0 5692 376 pts/4 Ss+ 21:20 0:00 /usr/bin/kdesu_stub -
root 7990 0.0 0.2 26324 1084 pts/5 Ss+ 21:20 0:00 /usr/bin/sudo -u root /usr/bin/kdesu_stub -

Neither running "sudo -k" nor "kdesu -s" makes kdesu functional again.

[^rooker (rooker)]

Forgot to mention, that this causes incredible confusion when trying to open "administrator mode" in KDE's system settings - the frame turns red and nothing happens.

[Nicolai Hähnle (nha)]

On Monday 26 February 2007 21:24:15 ^rooker wrote:
> Neither running "sudo -k" nor "kdesu -s" makes kdesu functional again.

That's because "sudo -k" only removes the timestamp corresponding to the
current pseudo terminal, and kdesu starts sudo on a different pseudo
terminal.

A workaround is to run "sudo rm /var/run/sudo/yourusername/*". This removes
the timestamp files for all pseudo terminals.

[kko (kko)]

"A workaround is to run 'sudo rm /var/run/sudo/yourusername/*'."

...except that you can't do this, because the shell fails to replace the "*" with the correct filenames (it doesn't have read permissions to the directory). You would have to do a 'sudo ls' on the directory and remove each timestamp ticket separately, manually entering the correct filename.

The following works better:
'sudo su'
'rm /var/run/sudo/yourusername/*'
'exit'

About other workarounds (from bug #72545):
 - Opening a couple new instances of Konsole occupying some new pts's should normally help.
 - Also, you can set the option "timestamp_timeout=0" in '/etc/sudoers', which will force 'sudo' to always ask for the password.

[Vermithrax (shzl2qr02)]

Yes, I'm seeing this problem also. :) I'll keep an eye on this bug report, though I presume it'll be closed shortly. :)

[Kieran Hogg (xerosis)]

Bug seems to fixed in Gutsy, marking as fixed released. Please re-open if you come across this bug.

[Daniel Hahler (blueyed)]

This seems to be an important bug, which should get fixed in Feisty, too - if possible.

[Laur Mõtus (vprints)]

I absolutely agree with dAniel.

[Kieran Hogg (xerosis)]

Assigning to backports.

[Epson (epson-deactivatedaccount)]

Unable to open kate, konqueror using kdesu.
I'm using Mint 4.0 miniKDE CE.
KDE v3.5.8.
After rebooting, I was able to use kate and konqueror with kdesu.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

Marking as wontfix - hardy has been EOL'd.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

er, s/hardy/feisty/