Bug 115898

I have absolutely the same problem already a long time, actually only in a a newer KDE version:
Qt: 3.3.5
KDE: 3.5.0 Level "a" (SuSE 10.0 unsupported)
KDE su: 1.0
The problem iccured in earlier KDE versions for me, too, at least 3.4.2.

Steps to reproduce:
- Restart Yast2 Control Center as a "normal user" more times as often as the kdesu dialog appears. Most probable it will fail sometimes. Not savely to reproduce.

i have the same problem in kubuntu, alot of times kdesu wont do anything. ill try to run a program that is supposed to pop up a kdesu box first and it doesnt nothing. it gets really annoying! i'd gladly donate money to get this bug fixed once and for all!

I have run into what I believe to be this bug in Kuntu Feisty betas. I have investigated, including steps to reproduce and a possible explanation of where this bug comes from:

https://launchpad.net/ubuntu/+source/kdebase/+bug/50971

*** Bug 140646 has been marked as a duplicate of this bug. ***

This should be fixed in 3.5.7.

I backported all the patches from this branch:

http://websvn.kde.org/branches/KDE/3.5/kdebase/kdesu/kdesud/kdesud.cpp?view=log

to 3.5.6, but I still see the hang described in this bug. Are there additional patches that I need to apply?

its still there, i dont think this bug will ever get squashed. ive found out that it always works the second time though.

I can confirm that this bug is still present in the kde 3.5.7 packages provided by Kubuntu 7.04.

Steps to reproduce:
* open konsole
* sudo ls (or some other command)
* close konsole
* Alt-F2 -> run: kdesu kwrite

-> no password prompt, kdesu hangs:
wouterh  32534  0.0  0.0   1712   476 ?        S    11:32   0:00  \_ /bin/sh -c kdesu kwrite
wouterh  32535  0.4  1.1  26460 12156 ?        S    11:32   0:00      \_ kdesu kwrite
root     32538  0.0  0.0   1520   324 pts/9    Ss+  11:32   0:00          \_ /usr/bin/kdesu_stub -
root     32541  0.0  0.0   2632  1024 pts/11   Ss+  11:32   0:00          \_ /usr/bin/sudo -u root /usr/bin/kdesu_stub -

An adequate description of what is happening is in:
https://bugs.launchpad.net/ubuntu/feisty/+source/kdebase/+bug/50971/comments/13
and
https://bugs.launchpad.net/ubuntu/feisty/+source/kdebase/+bug/50971/comments/14

My opinion is that is there something fundamentally broken in the way kdesu handles the sudo backend (see also bug #20914).

Reopening.

*** This bug has been confirmed by popular vote. ***

I reported bug 143168 which seems to be very similar to, if not an actual duplicate of this bug.

I have not had this problem after upgrading to Kubuntu Gutsy, which uses the new kdesudo instead of kdesu. It was introduced in Kubuntu Gutsy Tribe 5, as seen at: https://wiki.kubuntu.org/GutsyGibbon/Tribe5/Kubuntu

The kdesudo page at kde-apps http://www.kde-apps.org/content/show.php/KdeSudo?content=72106 itself says that "KDE's normal kdesu doesn't deal correctly with sudo". And nice news is that kdesudo 2.0 was released just yesterday with package available for Hardy at http://packages.ubuntu.com/hardy/kde/kdesudo. (I already have backported it to Gutsy and installed.)

So to fix in KDE's SVN this bug and the other one which I reported, either you can merge from kdesudo's code or better still, meaning the cleaner way, just throw away kdesu and take kdesudo as an official KDE project, just like was done for Kicker (IIRC) and other code in the transit to KDE 4.

I don't see any place where a KDE GUI front-end to su is needed where having the same for sudo won't work. On the terminal, there's a difference -- su is effective over all following commands whereas sudo is only for the one command. But when opening apps with root permission (which is the main use for su/sudo) in a GUI, kdesudo will just do fine, methinks.

It would be OK with me if the other bug were marked a duplicate of this.

*** Bug 143168 has been marked as a duplicate of this bug. ***

Unfortunately just replacing kdesu with kdesudo will not do either. This may be a good solution in Ubuntu (esp. if it really is command-line compatible, now), but note that many other systems just do not have a read-configured sudo out of the box (but do have a working su). These two approaches just are not equivalent, and both have a reason for existing. So while the situation definitely needs to be improved, there is no trivial solution.

If you are interested in working on this, add your thoughts to http://techbase.kde.org/Projects/kdesu .

Can you please give me some example cases where a sudo frontend won't work and only a su frontend will? I mean, apart from the "many people don't have sudo" thing. 

In effect, I am asking you the "reason for existing" of a su front-end, when a sudo front-end exists.

I also did not understand that part about "read-configured sudo".

Sorry, "read-configured" was a typo for "ready-configured", and this is the crux about the matter: sudo needs to be configured, before it can be used. And there are two basic configuration choices:

a) Allow the user to do anything, i.e. essentially be root. kdesu already supports using sudo in this way (compilation and configuration option), and AFAIK it supports this reasonably well. However this setup pretty much defies the security advantage of sudo. And in fact I for one prefer to have a separate password for the adminstrative account, instead of making it available with the same user password. So such a setup simply can not be assumed or even enforced.

b) Fine-tuning which administrative commands the user may or may not run. Certainly the gold-standard for controlling admin privileges for not fully trusted users. However, this requires a lot of love to set up, so once again this cannot just be assumed.

sudo is not 100% "a better su". It is an entirely different approach. Ideally kdesu would support both at once, and allow the user to switch between the modes easily, if needed. Presently it's easy enough to just replace kdesu with kdesudo if that is wanted (and done in ubuntu), and if for you sudo is better on all counts, then I recommend you do so. But definitely just dropping su support, and assuming all users will be happy to use sudo instead, does not sound like a good plan.

Anyway, this is pretty OT for this bug report. Feel free to discuss further in the above mentioned wiki page or in private mail, but let's not continue this discussion in this unrelated bug report.

to summarize:

- the kdesu api in kdelibs offers a mode to check whether a password will be needed and one to actually execute a command, optionally with a password. this is broken by design, because sudo will behave differently on each call due to password caching and a dependency on the controlling terminal. a proper api would use a callback to query the password on demand.
- the implementation uses a stub which receives all its parameters via stdin instead of command line arguments. this completely subverts sudo's selective authorization model.

point one cannot be fixed until kde5. point two would be fixable now.

buut ... i think the most sensible approach is simply purging the "transparent" sudo support from kdelibs (and the entire kdesu api in kde5). for the frontend implementation, the kdesudo code should be merged - it's fairly simple. alternatively, see bug 20914.

*** Bug 136894 has been marked as a duplicate of this bug. ***

*** Bug 144281 has been marked as a duplicate of this bug. ***

*** Bug 157276 has been marked as a duplicate of this bug. ***

*** Bug 195127 has been marked as a duplicate of this bug. ***

hmpf. now i think that the original report is unrelated to most of the additional comments and the "duplicates" i added. it is duplicated by bug 208979 which has a useful log attached, so it can be tracked there.

This sounds like exactly the problems described in https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/50971/comments/14 - and 6 years after the initial report, the sudo backend in kdesu is still not working properly.

(In reply to comment #15)
> a) Allow the user to do anything, i.e. essentially be root. kdesu already
> supports using sudo in this way (compilation and configuration option), and
> AFAIK it supports this reasonably well. However this setup pretty much
> defies the security advantage of sudo. And in fact I for one prefer to have
> a separate password for the adminstrative account, instead of making it
> available with the same user password. So such a setup simply can not be
> assumed or even enforced.
No, it does not work "reasonably well", that's just the point of the bugreport. Bug 292176 seems to be merely a symptom: Even when I do always enter the password correctly, I get errors in auth.log about incorrect login attempts. Besides, the kdesu daemon is often blocking my system from shutting down cleanly, since it is still hanging somewhere.
Unfortunately, there does not seem to be a way to use kdesudo instead - even after installing it, applications which have "Run as a different user" checked in KMenuEdit do not use kdesudo, but kdesu (which does not exist as a binary anymore, I assume it's calling something from libkdesu).

>  kdesu (which does not exist as a binary anymore...)

It does, it's under /usr/lib[64]/kde4/libexec/kdesu

(In reply to comment #23)
> It does, it's under /usr/lib[64]/kde4/libexec/kdesu
Oh, sorry, I just checked the $PATH.