kdesu fails when invoked immediately after sudo from terminal

[Chandru]

Binary package hint: kdebase-bin

I have found that kdesu or probably something else, fails to ask for password when it tries to enter root mode and of course the application or systemsettings module fails to open. Here are three typical cases when I have the trouble.

Case-1:

1. I use sudo to run some command from konsole.
2. I try to open adept. It neither asks for password nor does it open.
3. I try to open adept again and it takes the password and opens successfully.

Case-2:

1. I use sudo to run some command from konsole.
2. I open "System Services" in systemsettings and click on "Administrator Mode" button. It neither asks for password nor does it open.
3. I try to click the "Administrator Mode" button in some other module and it takes the password and opens successfully but "System Services" module keeps failing.

Case-3:

1. I use sudo to run some command from konsole.
2. I open "Login Manager" in systemsettings and click on "Administrator Mode" button. It neither asks for password nor does it open.
3. I try to click the "Administrator Mode" button in some other module and it takes the password and opens successfully but "Login Manager" module keeps failing.

My interpretation is that any application or module trying to enter admin mode immediately after a sudo from terminal fails invariably for the first time. And while systemsettings modules fail continuously till a system reboot, application work in the second attempt.

[Freddy Martinez (freddymartinez9)]

This is a result of the system attempting to "recover" the sudo. That is, if you close a program, your system will recover that memory that was freed, but will take a little time to do it. While this time is not significant (shouldn't be more than 5 seconds) it is necessary that your system close sudo, and prepare sudo to be used. This isn't necessarily a bug.

[Chandru (chandru-in-deactivatedaccount)]

The time taken is very much significant (1 hour). In fact gets normal only when I restart the system. When I say immediate, I mean only the sequence and not the time interval between sudo from konsole and opening adept, etc.

[Jelle Raaijmakers (jelle-gmta)]

I can confirm this problem, but it occurs at random. When I use sudo in a console and immediately try to open Adept, it sometimes refuses to show the kdesu dialog.

[Freddy Martinez (freddymartinez9)]

Jera, do you also have a long time between the kdesu dialogue opening. For both of you, what happens when you type "exit" after you use sudo in the konsole and try to open Adept. Does this problem persist? What kind of systems are you both using? Do you have any ideas on ways to reproduce these bugs?

[Jelle Raaijmakers (jelle-gmta)]

I can't really tell how long it takes, often no more than a few minutes if I had to guess. I use Edgy and the easiest way to reproduce this is to do a 'sudo ...' in e.g. konsole, 'exit' and trying to run Adept as soon as possible. Sometimes it's (seemingly) persistent and the only thing that works is a 'sudo -k'.

[kko (kko)]

I just experienced this, trying to launch an application (synaptic) requiring kdesu after a number of commands involving sudo in a konsole. All I got was the launch feedback, but no kdesu dialog. A 'sudo -K' actually helped, oddly enough. And no, I don't currently have a way to reproduce this.

[Nicolai Hähnle (nha)]

This appears to be a duplicate of bug #50791. I have posted an explanation attempt there which may or may not be correct.

[kko (kko)]

A common typo. You mean bug #50971.

 I believe your interpretation of what happens is correct. Incidentally, I have been exploring this issue too, after my last comment, and meaning to post here in essence the same explanation as yours. (I arrived at the same conclusion based on observing what happens, and haven't looked at the code.)

[kko (kko)]

I will concisely document here my reasoning.

In essence, 'kdesu' needs two instances of 'sudo', and each 'sudo' needs a terminal (tty) or, in this case, a pseudo-terminal (pts). This is because '/etc/sudoers' defines that we are using "tty_tickets", i.e. that for each tty or pts we need to input the password separately.

Now, on a clean boot (that has removed all sudo tickets), if we open Konsole, do 'sudo foo' and input the password, we get a verified sudo ticket for pts/1. If we then close the Konsole, we free the pseudo-terminal.

When we after this invoke kdesu (which in turn invokes processes of kdesu_stub and sudo), the processes involved will use the first two available pseudo-terminals, 1 and 2. Now, pts/1 has a valid sudo ticket, and pts/2 doesn't, which confuses 'kdesu' and causes this bug.

(This explanation assumes that we have no other processes occupying a pts. The numbers of the pts's are not important, however, as this is perfectly reproducible even with other pairs of pts's. The only condition that needs to be met is that we have a valid sudo ticket for the first pts used by 'kdesu' and we don't have one for the second.)

[Chandru (chandru-in-deactivatedaccount)]

That was a clear explanation of what was happening. Is there a workaround for this? If so why shouldn't the workaround be made in the default installation so that newbies are not put off? Also, why is it that kdesu needs two instances of sudo?

[Sarah Kowalik (hobbsee-deactivatedaccount)]

Marking this a dupe of 72545.

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)

[kko (kko)]

About workarounds:
- Opening a new instance of Konsole (or two) 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. (This wouldn't be suitable for the default installation, IMO.)
- I think this is a rare enough occurrence that, more importantly, also goes away after you reboot (or wait a while), that putting in workarounds for this in the default installation shouldn't be needed. Much better to fix the cause than go around it.

[Freddy Martinez (freddymartinez9)]

Does sudo -k work as a workaround?
sudo apt-get update
sudo -k
kdesu kate /etc/apt/sources.list

[kko (kko)]

Yes, 'sudo -k' and 'sudo -K' should (and do) also remove the problem, if done on the right pseudo-terminal.

[Launchpad Janitor (janitor)]

[Expired for kdebase (Ubuntu) because there has been no activity for 60 days.]