Bug 419465 - Wallet failed to get opened by PAM, error code is -9
Summary: Wallet failed to get opened by PAM, error code is -9
Status: RESOLVED WORKSFORME
Alias: None
Product: kwallet-pam
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.18.4
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-31 20:04 UTC by Martin Droessler
Modified: 2020-06-05 04:33 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Droessler 2020-03-31 20:04:12 UTC
SUMMARY
Since Update to 5.18.4 kwallet fails to open!
In the journal I encountered the following warning:
"Wallet failed to get opened by PAM, error code is -9"
Trying to open the wallet manually failed - it refused to accept my password!
Downgrading to version 5.18.3 solved the issue.


STEPS TO REPRODUCE
1. Update to kwallet-pam 5.18.4
2. Login as usual
3. try to do anything, that relies on kwallet (e.g. open chromium)

OBSERVED RESULT
Kwallet fails to open by PAM.
Kwallet refuses password when trying to open it manually.


EXPECTED RESULT
Kwallet will be opened by PAM.


SOFTWARE/OS VERSIONS
Archlinux
Linux: 5.5.13
KDE Plasma Version: 5.18.4
KDE Frameworks Version: 5.68.0
Qt Version: 5.14.1

ADDITIONAL INFORMATION
Much likely caused by change, mentioned in the changelog:
https://cgit.kde.org/kwallet-pam.git/commit/?id=2bb4c6dc870ff59c6f62c4b12bf9be229d9ff8da

I only downgraded kwallet-pam, and everything works again as expectd:
"pacman -U /var/cache/pacman/pkg/kwallet-pam-5.18.3-1-x86_64.pkg.tar.zst"
Comment 1 Ongun Kanat 2020-04-02 23:14:38 UTC
I don't get that error but I always get the password dialog after a cold boot. Kwallet pam becomes meaningless in this case.
Comment 2 Ongun Kanat 2020-04-02 23:19:15 UTC
Forgot to mention that. This behavior has started to occur with Plasma 5.18.0 update. The component asking Kwallet to open is kded5 my guess is that NetworkManager is the main trigger because it immediately connects my wifi after I entered the password.

Distro Info:
Arch Linux
Qt: 5.14.2
Plasma: 5.18.4
Frameworks: 5.68
Comment 3 Christoph Feck 2020-04-15 11:24:29 UTC
Interesting. Bug 416461 states that KWallet/PAM issues appeared with update to 5.18.3 for many people, but also earlier for the original reporter. I tend to believe that there not a Plasma update broke it, but some lower level component changed.

The only code change in kwallet-pam since a long time was indeed an update in 5.18.4 to support encrypted systems, see https://cgit.kde.org/kwallet-pam.git/commit/?id=2bb4c6dc870ff59c6f62c4b12bf9be229d9ff8da

It looks like this commit broke non-encrypted systems?
Comment 4 Albert Astals Cid 2020-04-15 21:22:58 UTC
(In reply to Christoph Feck from comment #3)
> Interesting. Bug 416461 states that KWallet/PAM issues appeared with update
> to 5.18.3 for many people, but also earlier for the original reporter. I
> tend to believe that there not a Plasma update broke it, but some lower
> level component changed.
> 
> The only code change in kwallet-pam since a long time was indeed an update
> in 5.18.4 to support encrypted systems, see
> https://cgit.kde.org/kwallet-pam.git/commit/
> ?id=2bb4c6dc870ff59c6f62c4b12bf9be229d9ff8da
> 
> It looks like this commit broke non-encrypted systems?

@Martin Interesting I'm using that version both in encrypted and non-encrypted systems (two different laptops) and it works fine.

Do have an actual password or is it a passwordless system? Are you using sddm or any other login manager?

@Ongun your thing seems different, please open a different bug report.
Comment 5 Oleg Solovyov 2020-04-24 09:06:23 UTC
Can this be a race condition between running kwalletd5 without parameters and running with "--pam-login X Y"?
Comment 6 Albert Astals Cid 2020-04-25 13:55:32 UTC
(In reply to Oleg Solovyov from comment #5)
> Can this be a race condition between running kwalletd5 without parameters
> and running with "--pam-login X Y"?

You mean from a kwalletd5 being restored by session restore?

As far as I know session restore kicks in much later, so it should not happen.

Do you have session restore enabled?
Comment 7 Andre Woebbeking 2020-05-01 20:07:35 UTC
I've this problem after updating Kubuntu 18.04 to 20.04. I also get error code -9. 

My home folder is encrypted with encrypfs and libpam-wallet* is version 5.18.4.

After reading this I also downgraded libpam-wallet* to 5.18.3 (from eoan updates) and it works. But only when I login the first time after booting. When I logout and relogin I get error code -9 again.

So I tried 5.18.4 again but that seems to be broken first and second login (I rebooted after upgrading).
Comment 8 Albert Astals Cid 2020-05-01 22:48:30 UTC
@Andre how does your encrypfs setup works?

It gets un-encrypted after you put the password using pam?

I wonder how this may work at all with 5.18.3 since your user dir is still encrypted and thus it can not read from it.

Is it possible that there's a .local/share/kwalletd/kdewallet.salt in your home "outside" the encrypted data?

I've no idea how encrypfs works, but if it works by mounting something on top of your existing home dir, i can envision the fact that there's a /home/youruser/.local/share/kwalletd/kdewallet.salt "outside" your encrypted data and then another one inside.

Can you try that? e.g. by logging as root or as another user and checking if the file is there?

If that's the case, that's unfortunately a bug of how kwallet-pam used to work, that file should be *inside* your encrypted data and not outside, so a way to fix this would be copying that file from outside your encrypted data to the inside (keep copy of the old one just in case).

Am i making sense?
Comment 9 Andre Woebbeking 2020-05-02 10:28:07 UTC
(In reply to Albert Astals Cid from comment #8)
> @Andre how does your encrypfs setup works?
> 
> It gets un-encrypted after you put the password using pam?

I think so. It was an option while installing Kubuntu.

> I wonder how this may work at all with 5.18.3 since your user dir is still
> encrypted and thus it can not read from it.
> 
> Is it possible that there's a .local/share/kwalletd/kdewallet.salt in your
> home "outside" the encrypted data?
> 
> I've no idea how encrypfs works, but if it works by mounting something on
> top of your existing home dir, i can envision the fact that there's a
> /home/youruser/.local/share/kwalletd/kdewallet.salt "outside" your encrypted
> data and then another one inside.
> 
> Can you try that? e.g. by logging as root or as another user and checking if
> the file is there?

It's, also one in ~/.kde/share/apps/kwalled.

> If that's the case, that's unfortunately a bug of how kwallet-pam used to
> work, that file should be *inside* your encrypted data and not outside, so a
> way to fix this would be copying that file from outside your encrypted data
> to the inside (keep copy of the old one just in case).

First I moved them away, and got error code -9 with 5.18.3 and 5.18.4 at first and second login.

Then I moved them inside and 5.18.4 works as expected, first and second login :-)
 
> Am i making sense?

Well, you fixed my problem :-)

Thank you very much!

Not sure whether kwallet could warn about my problem otherwise this should be documented somewhere.
Comment 10 Albert Astals Cid 2020-05-02 14:38:15 UTC
@Martin can you check if you're having the same problem as Andre?
Comment 11 Albert Astals Cid 2020-05-02 14:39:57 UTC
@Andre the problem here is that there's nothing really kwallet can do, since when kwallet is run the kwallet.salt from "outside" the encrypted mount is not visible anymore and all it knows is the password given with the .salt from inside doesn't work.

I'll try to work on a blog explaining which may be the issue for people that have it
Comment 12 Christoph Feck 2020-05-06 20:52:35 UTC
Thanks Albert for publishing your investigations.

Martin, could you please check if https://tsdgeos.blogspot.com/2020/05/kwallet-pam-5184-and-ecryptfs-homes.html resolves your issue?
Comment 13 Bug Janitor Service 2020-05-21 04:33:21 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 14 Bug Janitor Service 2020-06-05 04:33:16 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!