Bug 504193

Might be a Neon problem of not rebuilding Plasma packages along with this update. Cannot reproduce on Fedora 42 with all KDE software build from source.

Tested on Solus, which updated to 6.14 this morning, I had just rebooted after updates this morning. I can't reproduce

KMail opened and fetched mail without issue
I ran Wallet Manager, and saw the default wallet was open as expected

I have the exact same issue. The wallet does not open automatically, nor when clicking on the button.
Also the same error message in the logs. (Would be nice to have something on the screen as well)

It broke with the updates from yesterday.
Downgrading kf6-kwallet and  kf6-kwallet-libs from 6.14.0-2.fc42 to 6.12.0-1.fc42 helped.
I can help with debugging/backtraces if needed.

OS: Fedora 42

With all passwords in KWallet I couldn't even login to add this comment ... because all my passwords were gone ;)

I'm setting this to major as it makes several applications unusable.(In reply to Arek Guzinski from comment #0)
> I'm setting this to major as it makes several applications unusable.

If people do not have a 2nd password manager this is a serious problem to login anywhere, not just some apps.

can another wallet be created and opened?

(In reply to Marco Martin from comment #5)
> can another wallet be created and opened?

Yes, that works. Created a new "classic wallet", which seems to be operable. The 2nd wallet make the sidebar appear showing all the available wallets. Clicking the main wallet there also doesn't open it.

(One caveat, the kwalletmanager is unable to create entries in the new wallet. But that may be because the new wallet in completely empty yet and the UI is not prepared to handle this case.)

I ran strace on kwalled6 with no suspicious output. I does not try to open/access any file that is unavailable.
Only saw plenty of DBus activity, which is then likely the cause.

Not sure what to debug next.

I've recorded some DBus communication:

method call sender=:1.144 -> destination=org.kde.kwalletd6 serial=95 path=/modules/kwalletd6; interface=org.kde.KWallet; member=open
   string "xxxxx"
   int64 xxxxxxxxxxxxxx
   string "kwalletmanager"

method call sender=:1.140 -> destination=:1.118 serial=43 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=Unlock
   array [
      object path "/org/freedesktop/secrets/collection/XXXXXX"
   ]
method return sender=:1.118 -> destination=:1.140 serial=159 reply_serial=43
   array [ ]
   object path "/org/freedesktop/secrets/prompt/p13"

method call sender=:1.140 -> destination=org.freedesktop.DBus serial=44 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.kde.secretservicecompat',interface='org.freedesktop.Secret.Prompt',path='/org/freedesktop/secrets/prompt/p13'"

Then there are some actions on that "prompt".

signal sender=:1.118 -> destination=(null destination) serial=161 path=/ksecretd; interface=org.kde.KWallet; member=walletAsyncOpened
   int32 13
   int32 -1
signal sender=:1.118 -> destination=:1.140 serial=162 path=/org/freedesktop/secrets/prompt/p13; interface=org.freedesktop.Secret.Prompt; member=Completed
   boolean true 
   variant       array [  ]   
method call sender=:1.144 -> destination=org.freedesktop.DBus serial=96 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.kde.kwalletd6',arg2=''"
method call sender=:1.144 -> destination=org.freedesktop.DBus serial=97 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.kde.kwalletd6"

method return sender=org.freedesktop.DBus -> destination=:1.144 serial=xxx reply_serial=97
   boolean true

method call sender=:1.144 -> destination=org.kde.kwalletd6 serial=98 path=/modules/kwalletd6; interface=org.kde.KWallet; member=isOpen
   string "xxxxx"
method return sender=:1.139 -> destination=:1.144 serial=70 reply_serial=98
   boolean false

May the problem be that it is asking for the password ("prompt") but it just doesn't show a window?

Some notable points from your trace:

- The `walletAsyncOpened` is broadcast with the 2nd parameter set to -1. This indicates that the open operation failed: https://invent.kde.org/frameworks/kwallet/-/blob/master/src/runtime/ksecretd/ksecretd.cpp#L278
- The `interface=org.freedesktop.Secret.Prompt; member=Completed` signal is sent with its 1st parameter set to `true`. This indicates that the prompt was dismissed: https://specifications.freedesktop.org/secret-service-spec/latest/org.freedesktop.Secret.Prompt.html#org.freedesktop.Secret.Prompt.Completed
- Finally `org.kde.KWallet; member=isOpen` returns false, since the open failed.

I could only find one place in the sources where the prompt is dismissed internally: https://invent.kde.org/frameworks/kwallet/-/blob/master/src/runtime/ksecretd/kwalletfreedesktopprompt.cpp#L86

I've attached a debugger and it is indeed the Dismiss() call.

(gdb) n
KWalletFreedesktopPrompt::walletAsyncOpened (this=0x7f1c0400ce60, transactionId=6, walletHandle=-1) at /usr/src/debug/kf6-kwallet-6.14.0-2.fc42.x86_64/src/runtime/ksecretd/kwalletfreedesktopprompt.cpp:86
86                  Dismiss();

Seems the walletHandle passed to this function is invalid.

The call originates from https://invent.kde.org/frameworks/kwallet/-/blob/master/src/runtime/ksecretd/ksecretd.cpp#L281

I found the culprit at https://invent.kde.org/frameworks/kwallet/-/blob/master/src/runtime/ksecretd/ksecretd.cpp#L1814

Turns out the app "KDE System" was in the deny list of the wallet. Removing that item in the wallet settings, restarting kwalletd and ksecretd solves this issue for me.

I was not aware that I had this app in the deny list, and am 100% sure I did not add it in the last month. Weird that one version of KDE ignores this or added it automatically. Anyways, a message box saying "Your access has been blocked from your settings" would have been nice.  Just clicking the button and nothing happens is Windows style ;)

(In reply to Rainer from comment #12)
> Turns out the app "KDE System" was in the deny list of the wallet.
> Removing that item in the wallet settings, restarting kwalletd and
> ksecretd solves this issue for me.

Arek Guzinski, can you check your deny list in the wallet settings? Does this fix work for you?

(In reply to Rainer from comment #12)
> I found the culprit at
> https://invent.kde.org/frameworks/kwallet/-/blob/master/src/runtime/ksecretd/
> ksecretd.cpp#L1814
> 
> Turns out the app "KDE System" was in the deny list of the wallet. Removing
> that item in the wallet settings, restarting kwalletd and ksecretd solves
> this issue for me.

and did old kwallet work with the same app in the deny list?

did it also end up in "Auto Deny" in the config file?

(In reply to Marco Martin from comment #14)
> and did old kwallet work with the same app in the deny list?

Yes, it did. But I didn't check the list back then. For sure I haven't added it.

My assumtion is that the application name has changed with the update. As mentioned, when opening from KWalletManager, it looks for "KDE System" in the list. My assumption would have been something along "KWalletManager", or similar.
Just "KDE System" sounds a bit odd because from that you can not determine which application is actually requesting the wallet.

Thread 1 "ksecretd" hit Breakpoint 1, KSecretD::implicitDeny (this=0x7ffc1a2799d0, wallet=..., app=...) at /usr/src/debug/kf6-kwallet-6.14.1-1.fc42.x86_64/src/runtime/ksecretd/ksecretd.cpp:1814
1814        return _implicitDenyMap[wallet].contains(app);
(gdb) p app
 $1 = (const QString &) @0x7ffc1a2790f0: {d = {d = 0x0, ptr = 0x561a4c0af144 u"KDE System", size = 10}, static _empty = 0 u'\000'}

> did it also end up in "Auto Deny" in the config file?

I only checked the wallet settings.

(In reply to michaelk83 from comment #13)
> (In reply to Rainer from comment #12)
> > Turns out the app "KDE System" was in the deny list of the wallet.
> > Removing that item in the wallet settings, restarting kwalletd and
> > ksecretd solves this issue for me.
> 
> Arek Guzinski, can you check your deny list in the wallet settings? Does
> this fix work for you?

Yes, this fixes it :)

I also can't remember to ever have put KDE System there. So the question is: how did it get there?

(In reply to Arek Guzinski from comment #17)
> I also can't remember to ever have put KDE System there. So the question is:
> how did it get there?

"KDE System" is the fallback string when the app name is not known. It's used in ksecretd.cpp lines 572 (KSecretD::internalOpen()) and 837 (KSecretD::isAuthorizedApp()). The only place where I see it added to the deny list is in ksecretd.cpp line 879, in reponse to the user authorization dialog. I also checked a commit from before 6.14, and it's the same there.

I think the only thing we can do here is try to pass a more specific app name when possible, at least from KWalletManager. Other that, it seems to be working as intended.

in the code i also only see the _implicitDenyMap being populated from the config file, but no writing in anything from kwallet, that config seems to just be written by kwalletmanager

(In reply to michaelk83 from comment #18)
> I think the only thing we can do here is try to pass a more specific app
> name when possible, at least from KWalletManager. Other that, it seems to be
> working as intended.

still, not sure how it got written in the deny list config?

(In reply to michaelk83 from comment #18)
> I think the only thing we can do here is try to pass a more specific app
> name when possible, at least from KWalletManager.
That is a good idea. "KWalletmanager" is configured in my list as well, as "Allow". But with the name not used, this will never trigger.

Another helpful change would be a message box when clicking the "open" button in KWalletManager saying "Access to the wallet has been rejected [OK]", instead of doing nothing. Then people might be investigating their settings sooner.

(In reply to Marco Martin from comment #19)
> no writing in anything from kwallet

ksecretd.cpp line 874-882 in KSecretD::isAuthorizedApp(), after the user selects "Deny Forever" (response == 3), it gets written back to the config.

(In reply to Rainer from comment #21)
> Another helpful change would be a message box when clicking the "open"
> button in KWalletManager saying "Access to the wallet has been rejected
> [OK]", instead of doing nothing. Then people might be investigating their
> settings sooner.

I'd rather it be a system tray notification. No need to bother the user with random dialog popups. Also, specify which wallet was denied.

> I think the only thing we can do here is try to pass a more specific app name when possible, at least from KWalletManager. Other that, it seems to be working as intended. 

That would be a start.. but the more I think about it, the more questions of security pop up.
1. What is keeping me from making some malware that identifies itself as "KDE System" to get access to all passwords?
2. What if an app should have access to certain passwords, but misuses that privilege to access other passwords?

I think kwallet/ksecretservice should ..
1. not give access to the whole wallet, but only to specific entries (while giving the user a way to redirect it to another wallet).
2. identify apps by full paths (and always show these in dialogs) and warn the user if these are user-writeable.

It might also be a good idea to save the date of the grant/denial.

> I'd rather it be a system tray notification. No need to bother the user with random dialog popups. Also, specify which wallet was denied.

Yep, I second that - having to click a button every time that happens might be quite annoying.

(In reply to michaelk83 from comment #23)
> I'd rather it be a system tray notification. No need to bother the user with
> random dialog popups. Also, specify which wallet was denied.

Seems I was misunderstood here. I am *not* suggesting that the kwallet daemon should be showing the popup because that would be annoying when apps continue issuing requests repeatedly.
I mean the client requesting access on the user behalf should show the popup that it was not able to complete my request.

For example:
1. In KWalletManager I click the "open" button.
2. KWalletManager gets the DBus response that the request was denied.
3. KWalletManager informs me that my request to open the wallet was denied.

(In reply to Arek Guzinski from comment #24)
> 1. What is keeping me from making some malware that identifies itself as
> "KDE System" to get access to all passwords?
> 2. What if an app should have access to certain passwords, but misuses that
> privilege to access other passwords?

These are known limitations in all Linux password managers, and it's probably not any better in other OSes. There are too many ways for apps to impersonate another app. Short of placing each app in its own user or sandbox, there isn't much that a password manager can do against that. Malwares have other attack vectors as well.

There was *some* talk in KeePassXC to identify client apps more robustly, but even the solution that was discussed there isn't bulletproof. This is why you need to protect your user account first of all. If you get a malware on your user account, all bets are off.

But this is getting off topic.

(In reply to Rainer from comment #25)
> I mean the client requesting access on the user behalf should show the popup
> that it was not able to complete my request.

That would depend on each client app. We can at most do that in KWalletManager. But most users rarely need to touch KWalletManager itself, and most access requests are not from there.

i think i have the same problem, i dont know what to do and im not getting any suggestions on the manjaro forum

I’m running Manjaro with Plasma 6.3.5 and I’ve hit an issue where Dolphin hangs for a long time when trying to open an SFTP bookmark. I also noticed KWalletManager hangs or fails to open.

Digging into it, I found this error:

An error occurred when connecting to the KWallet service:
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.

I checked the process:

ps -ef | grep kwalletd

It shows kwalletd6 is running, but when I run it manually with debugging:

KWALLET_DAEMON_DEBUG=1 kwalletd6

…I get repeating messages like:

libsecret-CRITICAL **: secret_service_load_collections_sync: assertion 'paths != NULL' failed kf.wallet.kwalletd: "Could not connect to Secret Service"

(In reply to jackdinn from comment #27)

Hangs are a different problem than the one discussed in this bug report. Since your kwalletd6 is running, and the hanging apps are not Chromium-based, this doesn't look like bug 504014, but might be bug 458085 or a separate bug. Please post a separate issue with the full details, including your kwalletrc.

(In reply to michaelk83 from comment #28)
> (In reply to jackdinn from comment #27)
> 
> Hangs are a different problem than the one discussed in this bug report.
> Since your kwalletd6 is running, and the hanging apps are not
> Chromium-based, this doesn't look like bug 504014, but might be bug 458085
> or a separate bug. Please post a separate issue with the full details,
> including your kwalletrc.

ok, thx.i shall post something.