ksshaskpass hangs forever when run from keychain during KDE login

[Tais P. Hansen]

I start keychain in my .bashrc like this:
eval $(keychain --eval id_rsa)

The .bashrc is run in the Yakuake console which is started during KDE login.

It attempts to load my ssh key and invokes ksshaskpass to ask for my password, which in turn invokes kwallet. Nothing happens at this point. Other applications have no problem accessing kwallet during this. Only solution seems to be to disable and reenable the kwallet subsystem and rerun keychain.

Output while hanging:

KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/
Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL

 * Found existing ssh-agent (2947)
 * Found existing gpg-agent (3663)
 * Adding 1 ssh key(s)...
ksshaskpass(3861)/kdeui (Wallet) KWallet::Wallet::openWallet: Pass a valid window to KWallet::Wallet::openWallet().

This problem did not exist in Natty, Maverick and Lucid.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: ksshaskpass 0.5.3-1build1
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Fri Oct 14 13:03:50 2011
EcryptfsInUse: Yes
InstallationMedia: Kubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427)
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ksshaskpass
UpgradeStatus: Upgraded to oneiric on 2011-10-14 (0 days ago)

[Andrei-mihaila (andrei-mihaila)]

Version: unspecified (using KDE 4.5.2)
OS: Linux

This happens most of the times at system startup when both say... KMail/Kontact and Pidgin with the KWallet plugin (http://kde-apps.org/content/show.php/Libpurple+KWallet+Plugin?content=127658 ) try to open the default wallet. If Pidgin goes first everything is ok, if KMail goes first and Pidgin second kwalletd seems to lock. In a few seconds the Pidgin plugin gets a timeout and KMail hangs. I have to restart kwalletd in order for it to work (only tried by killing it and starting it again).

Reproducible: Always

Steps to Reproduce:
I've tried to make it as easy as possible to reproduce using qdbus. Assuming there is a wallet called kdewallet the next 2 lines should make kwalletd lock.

qdbus org.kde.kwalletd /modules/kwalletd org.kde.KWallet.open kdewallet 1 'Test1' &
qdbus org.kde.kwalletd /modules/kwalletd org.kde.KWallet.open kdewallet 2 'Test2' &

Actual Results:
The response after a few seconds is:

Error: org.freedesktop.DBus.Error.NoReply
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Error: org.freedesktop.DBus.Error.NoReply
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

And after that any request for kwalletd hangs if via the C++ interface or gets timed-out if via D-BUS.

Expected Results:
The D-BUS request should be handled correctly - that is queued. After the user answers the first request the second should be shown. If the user takes too long to respond (enter password/click Allow) and you can't find another solution but to give it a timeout - that should be transparent so that the application would know it needs to try and connect again.

I had a look at the kwalletd code (it was early this spring, maybe things changed since then) and couldn't find anything obviously wrong... I'm thinking it could be the generated D-Bus wrapper.

Thanks in advance for solving this (or at least for reading my report).

[Andrei-mihaila (andrei-mihaila)]

Still there in KDE versions 4.5.3 to 4.6. I wish I could find some time to hunt the problem myself ... Thanks for reading anyway.

[Jfergem (jfergem)]

I stumbled over this bug, too, with Chromium and Kopete locking up kwalletd.

[Andrei-mihaila (andrei-mihaila)]

Still there in KDE 4.6.4... Additionally, found that after kwalletd is locked the wallet manager shows it as being empty, although it is not (after restarting the daemon all my passwords were there).

[Daniel-pena-arteaga (daniel-pena-arteaga)]

I also found this problem with KDE SC 4.6.5 in Archlinux. For example, Akonadi IMAP resources will just hang there without being updated, no passwords shown in kwalletmanager, no way to create new wallets, chromium unable to fill password fields if just started, ... If I then kill kwalletd, suddenly the dialogs asking for all password appear, just like without using kwallet, and everything seems to be fixed until next kwallet hang.

[Zersaa (zersaa)]

Same problem with Kopete and Chromium, KDE 4.7.1

[Tais P. Hansen (taisph)]

I noticed that when this problem occurs opening a wallet also seems to hang. The wallet opens but the wallet looks empty and it is not possible to add or delete entries. Once the KDE wallet subsystem is disabled and reenabled, the wallet works again. This might be more of a KDE wallet problem, than ksshaskpass.

[Bugs-phlogi (bugs-phlogi)]

I can confirm this bug, also running arch linux.

[Bugs-phlogi (bugs-phlogi)]

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

[Tais P. Hansen (taisph)]

I can confirm this behavior.

I use keychain with ksshaskpass in my bashrc, so I have to -KILL kwalletd every single time I log in to KDE and want to use the console.

[Gábor Gludovátz (gabor-gludovatz)]

Same problem with KMess and KRDC. KDE 4.7.3.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sven-Hendrik Haase (svenstaro)]

Same problem in KDE 4.8.1.

[Cognifloyd (cognifloyd)]

This looks like an old bug: #123583

I have ksshaskpass and google-chrome cause some kind of race condition hanging ksshaskpass, and kwalletd. Google-chrome continues like nothing happened, except that it doesn't have any saved passwords (as expected with this issue).

I'm in gentoo with kde 4.8.3 with a 64 bit kernel.

[reagle (joseph.reagle)]

Still present in 4.9.4 .... still using the X or gnome ssh-askpass....

[Frederic-coiffier-k (frederic-coiffier-k)]

Still present in KDE 4.9.98 (alias 4.10 RC3).
And seems much more annoying than previously...

[U-kde (u-kde)]

This problems hits me while starting KDE (version 4.9.5 on kubuntu 12.10) with both network manager plasma widget and chromium: kwalletd hangs and must be killed to get things working again :-(!

Any news on this annoying issues?

[predder (predder)]

Is this actually being worked on?

It's rather high impact if kwallet is being used to store wireless passwords. I was unable to get online until I figured out what was going on and disabled the wallet.

More duplicates:
https://bugs.kde.org/show_bug.cgi?id=307731
https://bugs.kde.org/show_bug.cgi?id=259229

[Christoph-maxiom (christoph-maxiom)]

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

[Gael Beaudoin (gaboo)]

Getting the same problem upon a session restore. If I have no application asking for a password at startup, then kwalletd works fine. If anything asks for a password during startup/session restore (chrome, chokoq or amarok in my case), then they never get the password and behave abnormally.

Kubuntu 12.10 64bits, KDE 4.10.

[Jürgen Sauer (juergen-sauer)]

Same problem as here. Ugly Bug.

[Milos Jakubicek (xjakub-fi)]

Same problem here, definitely not Gentoo specific (I'm using Fedora).

[Frederic-coiffier-k (frederic-coiffier-k)]

Still present in 4.10.2

[Frederic-coiffier-k (frederic-coiffier-k)]

In my case, the problem was due to the ownCloud client : if this one isn't restored at the session start, the problem disappears.

[Woelfel (woelfel)]

Frédéric, is it possible that this is because if you don't start the client then there is no more concurrent access to kwallet by two clients?

[Woelfel (woelfel)]

B.t.w. I have the same problem with openSUSE kde 4.10.2 binaries. I "fixed" it by removing the kwallet password.

[Frederic-coiffier-k (frederic-coiffier-k)]

Philipp, in my case, at KDE session startup, many applications are restored at the same time and several of them require a kwallet access : akonadi (2 x POP3, Google resources...), konqueror, amarok, firefox, kopete.

[Michael Aquilina (michaelaquilina)]

I can confirm this issue occurs to me too. In my case wifi gets stuck authenticating and i have to kill and restart kwalletd in order to fix the issue at each startup.

[Christo Candiotes (christo-candiotes)]

I have the same issue only at startup with possibly a race condition as mentioned earlier in this bug report. Running Manjaro 0.8.6 with KDE 4.10.5. Symptoms is that my instant messaging (KDE Telepathy), KMail etc cannot connect being unable to get the passwords from KWallet. Manually opening the wallet in KWallet Manager gives NO entries in the opened wallet. Merely closing the wallet and re-opening does not help. Only workaround for me is to go to Settings->System Settings->Account Details->KDE Wallet then untick "Enable the KDE wallet subsystem" (thereby killing the current instance of KWalletManager and then just ticking it again and Apply it. All works fine then until next reboot. Hope this can point someone in the right direction to resolve this bug.

[Lieven-vanacker (lieven-vanacker)]

I can confirm the above. Also running on KDE 4.10.5. Only workaround is to set an empty password on the wallet, which completely misses the intended purpose of the application. I cannot understand the lack of attention to this bug, cause it renders the complete DE very insecure.

[8-kde (8-kde)]

Found race condition in the wallet opening logic. Working on it...

[8-kde (8-kde)]

The wallet gets locked because of the nested event loops and in the situation where the calling application doesn't have a main window, just like the qdbus call exposed by Andrei. It seems that the password prompt needs some window to attach to and if such a window is given, via the wId open method parameter, then the wallet won't lock. This can be demonstrated by the KWallet Manager application, wich never locks the daemon. In fact, on my system, I never encountered this lock proble.

I'll continue the work and try to solve the problem, but it's a hard one. Meanwhile, I suggest a workaround. Your application should wait for the GUI thread to start, then initiate wallet open call taking care to give the main window's ID.

[Andrei-mihaila (andrei-mihaila)]

@Valentin:
First of all thank you very much for investigating this issue.

Tried the workaround, don't know if I did it right, but it didn't work - started Amarok and KCalc (could be any 2 KDE apps) then ran in a terminal:
--------------
qdbus org.kde.kwalletd /modules/kwalletd org.kde.KWallet.open kdewallet `xwininfo -int -name 'KCalc' | grep 'Window id:' | cut -d' ' -f4` 'Test KCalc' &
qdbus org.kde.kwalletd /modules/kwalletd org.kde.KWallet.open kdewallet `xwininfo -int -name 'Amarok' | grep 'Window id:' | cut -d' ' -f4` 'Test Amarok' &
--------------

Got roughly similar results to what I wrote in the initial bug report:
--------------
Error: org.freedesktop.DBus.Error.NoReply
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
--------------

and a locked kwallet.

I wish I could help with the fix but I don't have enough QT knowledge (if at all - I was able to tell that the lock happens when the nested event loop starts but didn't know why).
When creating the fix one should bear in mind that there might be cases when a window-less client asks for access to KWallet (for example subversion or git). So for this kind of situation it may be better to have a totally independent thread/process that waits for the wallet to open and then sends the result back to the caller.

[8-kde (8-kde)]

@Andrei

I suppose you didn't wait to enter the password in the open dialog popped by the first command. Isn't it?
If you enter the correct password and the wallet opens, kwalletd no longer gets stuck.

If I'm correct, then you hit another bug I already planned to fix. That one is about a rush condition when opening wallet.

[Andrei-mihaila (andrei-mihaila)]

@Valentin
Yes, you are correct. That was the issue that I always had at start-up when 2 apps request access to KWallet almost at the same time (and can't make them wait for each other - in which case it would work fine).

OK, I look forward to your solution.

[Gael Beaudoin (gaboo)]

This is a very annoying bug, thanks you very very much for working on this @Valentin Rusu !

[8-kde (8-kde)]

Fixed the bug in kwalletd by kdelibs/kwallet needs also fixing. Please hold on, as I need to commit both in order to prevent regressions.

[8-kde (8-kde)]

Git commit b0f9053ed8abff4ef973b10842f761422ee17f41 by Valentin Rusu.
Committed on 31/08/2013 at 23:28.
Pushed by vrusu into branch 'master'.

Fix the synchronous-mode wallet open logic

The wallet synchronous open requests now use qdbus delayed replies.
The execution path now returns to the main event loop instead of
a nested event loop. The wallet opening UI logic is correctly handled
no longer leading to a frozen kwalletd.

Beware that this commit should be used along with the corresponding
fix of the kdelibs/kdeui module. Failing to updating kdelibs lead to
an aparently similar freeze condition, as kdeui also used an internal
event loop, faking synchronous operation when making async kwalletd calls.

M +0 -1 kwalletd/CMakeLists.txt
M +53 -21 kwalletd/kwalletd.cpp
D +0 -46 kwalletd/kwalletopenloop.cpp
D +0 -50 kwalletd/kwalletopenloop.h
M +1 -0 kwalletd/main.cpp

http://commits.kde.org/kde-runtime/b0f9053ed8abff4ef973b10842f761422ee17f41

[8-kde (8-kde)]

Git commit f8fea3f01c85eb0d6d479647ac27fe431846a1ae by Valentin Rusu.
Committed on 31/08/2013 at 23:16.
Pushed by vrusu into branch 'master'.

Fix the synchronous-mode wallet open logic

The wallet opening logic, for the synchronous mode, had a nested
event loops problem, leading to frozen kwalletd. That was because
kwalletd wasn't using qdbus delayed replies. kdelibs used
asynchronous open methods even for the synchronous mode, coupled
with an internal event loop to simulate synchronous mode.
This commit removes that internal event loop, as the kwalletd now
blocks on synchronous wallet open requests.

M +8 -20 kdeui/util/kwallet.cpp

http://commits.kde.org/kdelibs/f8fea3f01c85eb0d6d479647ac27fe431846a1ae

[8-kde (8-kde)]

Please note that this fix consists of two commits, one on kde-runtime and a corresponding on in kdelibs. You should absolutely update and build both modules in order to get the fix. Failing to do that, you get another case of kwallet freeze, in kdelibs this time.

[8-kde (8-kde)]

Git commit aff38f3cfeca0abb93e899c54f27e382cfa427ac by Valentin Rusu.
Committed on 01/09/2013 at 22:15.
Pushed by vrusu into branch 'frameworks'.

Fix the synchronous-mode wallet open logic

The wallet opening logic, for the synchronous mode, had a nested
event loops problem, leading to frozen kwalletd. That was because
kwalletd wasn't using qdbus delayed replies. kdelibs used
asynchronous open methods even for the synchronous mode, coupled
with an internal event loop to simulate synchronous mode.
This commit removes that internal event loop, as the kwalletd now
blocks on synchronous wallet open requests.

This commit has the same effect as f8fea3f01c85eb0d on kdelibs 4.11
but cherry-picking won't work because of KF5 source splitting. I just
redone it here.

M +9 -21 staging/kwallet/src/kwallet.cpp

http://commits.kde.org/kdelibs/aff38f3cfeca0abb93e899c54f27e382cfa427ac

[8-kde (8-kde)]

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

[8-kde (8-kde)]

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

[8-kde (8-kde)]

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

[8-kde (8-kde)]

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

[8-kde (8-kde)]

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

[8-kde (8-kde)]

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

[8-kde (8-kde)]

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

[xenoterracide (xenoterracide)]

Will this be in 4.11.1?

[8-kde (8-kde)]

Well, 4.11.1 has already been tagged, so no. It'll be 4.11.2
http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule

[Rdieter-math (rdieter-math)]

Valentin, I don't see your commits in the KDE/4.11 branch at all yet (only master, frameworks branches). did you mean to backport (or merge) them and forget?

[8-kde (8-kde)]

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

[8-kde (8-kde)]

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

[8-kde (8-kde)]

Git commit c5bdc96316e9e5f727085f65fcf8eb059ebf4357 by Valentin Rusu.
Committed on 31/08/2013 at 23:28.
Pushed by vrusu into branch 'KDE/4.11'.

Fix the synchronous-mode wallet open logic

The wallet synchronous open requests now use qdbus delayed replies.
The execution path now returns to the main event loop instead of
a nested event loop. The wallet opening UI logic is correctly handled
no longer leading to a frozen kwalletd.

Beware that this commit should be used along with the corresponding
fix of the kdelibs/kdeui module. Failing to updating kdelibs lead to
an aparently similar freeze condition, as kdeui also used an internal
event loop, faking synchronous operation when making async kwalletd calls.

M +0 -1 kwalletd/CMakeLists.txt
M +53 -21 kwalletd/kwalletd.cpp
D +0 -46 kwalletd/kwalletopenloop.cpp
D +0 -50 kwalletd/kwalletopenloop.h
M +1 -0 kwalletd/main.cpp

http://commits.kde.org/kde-runtime/c5bdc96316e9e5f727085f65fcf8eb059ebf4357

[8-kde (8-kde)]

Git commit 9027e0620d1f6bb06cbeb00db1072047ccb8ff13 by Valentin Rusu.
Committed on 31/08/2013 at 23:16.
Pushed by vrusu into branch 'KDE/4.11'.

Fix the synchronous-mode wallet open logic

The wallet opening logic, for the synchronous mode, had a nested
event loops problem, leading to frozen kwalletd. That was because
kwalletd wasn't using qdbus delayed replies. kdelibs used
asynchronous open methods even for the synchronous mode, coupled
with an internal event loop to simulate synchronous mode.
This commit removes that internal event loop, as the kwalletd now
blocks on synchronous wallet open requests.

M +8 -20 kdeui/util/kwallet.cpp

http://commits.kde.org/kdelibs/9027e0620d1f6bb06cbeb00db1072047ccb8ff13

[8-kde (8-kde)]

@Rex: thanks for pointing that out!

[Mathias-dietrich (mathias-dietrich)]

Thx for fixing this bug Valentin !
Great work, especially as it has some many votes.

[8-kde (8-kde)]

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

[David Pérez (sanete)]

It affects me now.
I'm using KUbuntu 13.04
Solution is to disable and reenable KWallet.

Chrome and ksshaskpass are both accessing KWallet at startup.

[Andrei-mihaila (andrei-mihaila)]

The bug is gone in my KDE 4.11.2 (tested using the 2 commands in my original report). Thank you Valentin!