Mailing List Archive

Does a new user account work the way it is supposed to?

On Sat, 10 Jun 2023, 07:33 Victor Ivanov, <vic.m.ivanov@gmail.com> wrote:

> Hello fellow penguins,
>
> I have to admit I'm at my wits' end with KWallet. This thing has been
> driving me insane for the last couple of weeks, roughly since the
> upgrade to Plasma 5.27 or shortly after.
>
> Every time I log in, it refuses to automatically open and prompts for
> a password whenever an application wants to read secrets. Admittedly,
> this is under Wayland which, following from recent news re this being
> the Gentoo preference, I decided to give a try. But this also happens
> under X11, so I doubt it's got anything to do with Wayland.
>
> I've tried everything I can think of:
> - I've double checked the auto unlock guide in the Gentoo Wiki, made
> sure PAM rules are in place and kwallet-pam is installed. Which should
> be all good regardless, as it used to work just fine;
> - I've also oneshot all of: kde-plasma/ , kde-frameworks/ , kde-apps/
> , and anything returned by "eix -I# pam", "eix -I# xdg", and "eix -I#
> dbus"
> - when the above failed to yield any meaningful resolution, I repeated
> the one-shot step this time with "--noconfmem" and re-reviewed any
> changes from the default configs;
> - finally, I nuked all of my $HOME settings under ~/.config, ~/.cache,
> and ~/.local and started from scratch;
> - and yes, the KWallet was set up and re-setup (plenty of times) with
> Blowfish with the same password as my login;
>
> The irony is, I have an equivalent Gentoo setup on a separate machine,
> also moved to Wayland at the same time as I keep them both up to date
> at the same intervals, and it works flawlessly. I've recursively
> diff'd all config files under /etc between the two hosts and, other
> than some minor, unrelated host-specific differences, everything is
> identical, including configs under /etc/pam.d.
>
> I can get it to kind of work with a blank password, but that's not the
> point and is not a viable "solution". Even then, it still doesn't auto
> open, but at least it doesn't produce annoying prompts to open.
>
> I've always despised KWallet for its flaky behaviour but for the last
> few years it hadn't given me any issues up until now.
>
> I'm truly bewildered. Is there anything I am missing?
>
> Best Regards,
> Victor
>
>

On Sat, 10 Jun 2023 at 12:58, Andrew Udvare <audvare@gmail.com> wrote:
>
> Does a new user account work the way it is supposed to?
>
Unfortunately, no. New accounts also get the same broken behaviour.

On Sun, 11 Jun 2023 13:47:44 +0100, Victor Ivanov wrote:

> > Does a new user account work the way it is supposed to?
> >
> Unfortunately, no. New accounts also get the same broken behaviour.

Anything in the logs? Maybe someting to indicate whether PAM is trying to
open the wallet and failing, or whether it is not trying at all.


--
Neil Bothwick

Why is there an expiration date on sour cream?

On Sun, 11 Jun 2023 at 14:22, Neil Bothwick <neil@digimed.co.uk> wrote:
>
> Anything in the logs? Maybe someting to indicate whether PAM is trying to
> open the wallet and failing, or whether it is not trying at all.
>
Thanks, Neil, good point. Not that I can tell. /var/log/auth.log looks
identical on both systems after cold boot login. Here's an example
(same on both hosts):

---
Jun 11 23:13:04 somehost sddm-helper: pam_unix(sddm-greeter:session):
session opened for user sddm(uid=****) by (uid=0)
Jun 11 23:13:06 somehost start-stop-daemon:
pam_unix(start-stop-daemon:session): session opened for user
pcscd(uid=(uid=****) by (uid=0)
Jun 11 23:13:15 somehost sddm-helper: gkr-pam: unable to locate daemon
control file
Jun 11 23:13:15 somehost sddm-helper: gkr-pam: stashed password to try
later in open session
Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:auth):
pam_kwallet5: pam_sm_authenticate
Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:setcred):
pam_kwallet5: pam_sm_setcred
Jun 11 23:13:15 somehost sddm-helper: pam_unix(sddm:session): session
opened for user *****(uid=*****) by (uid=0)
Jun 11 23:13:15 somehost sddm-helper: gkr-pam: gnome-keyring-daemon
started properly and unlocked keyring
Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:session):
pam_kwallet5: pam_sm_open_session
Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:setcred):
pam_kwallet5: pam_sm_setcred
Jun 11 23:13:17 somehost gnome-keyring-daemon[5636]: discover_other_daemon: 1
Jun 11 23:13:17 somehost polkitd[3881]: Registered Authentication
Agent for unix-session:2 (system bus name :1.48
[/usr/lib64/libexec/polkit-kde-authentication-agent-1], object path
/org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.utf8)
---

So it would appear "pam_kwalletd5" is loaded and initialised. There
are no errors It makes me wonder if gnome keyring is to blame and if
there's some sort of a race condition. On the other hand, there is the
message "discover_other_daemon: 1". Besides, if it were a race I would
expect KWallet to work at least some of the time on either system,
while the issue is always reproducible on one host and never on the
other.

Other logs such as "/var/log/sddm.log" and
"$HOME/.local/share/sddm/wayland-session.log" also look similar on
both hosts without anything related to KWallet.

I've also one-shot "eix -I# sddm" (SDDM owns sddm-helper) with
--noconfmem. Still no luck. Use flags are more or less identical on
both hosts as well.

Something is tricksing me badly and I'm one step from emerging @world
with --noconfmem and --empytree to see if that helps.

Hi Victor,

On Sat, 10 Jun 2023 12:33:21 +0100
Victor Ivanov <vic.m.ivanov@gmail.com> wrote:

> Hello fellow penguins,
>
> I have to admit I'm at my wits' end with KWallet. This thing has been
> driving me insane for the last couple of weeks, roughly since the
> upgrade to Plasma 5.27 or shortly after.
>
> Every time I log in, it refuses to automatically open and prompts for
> a password whenever an application wants to read secrets. Admittedly,
> this is under Wayland which, following from recent news re this being
> the Gentoo preference, I decided to give a try. But this also happens
> under X11, so I doubt it's got anything to do with Wayland.
>
> I've tried everything I can think of:
> - I've double checked the auto unlock guide in the Gentoo Wiki, made
> sure PAM rules are in place and kwallet-pam is installed. Which should
> be all good regardless, as it used to work just fine;
> - I've also oneshot all of: kde-plasma/ , kde-frameworks/ , kde-apps/
> , and anything returned by "eix -I# pam", "eix -I# xdg", and "eix -I#
> dbus"
> - when the above failed to yield any meaningful resolution, I repeated
> the one-shot step this time with "--noconfmem" and re-reviewed any
> changes from the default configs;
> - finally, I nuked all of my $HOME settings under ~/.config, ~/.cache,
> and ~/.local and started from scratch;
> - and yes, the KWallet was set up and re-setup (plenty of times) with
> Blowfish with the same password as my login;
>
> The irony is, I have an equivalent Gentoo setup on a separate machine,
> also moved to Wayland at the same time as I keep them both up to date
> at the same intervals, and it works flawlessly. I've recursively
> diff'd all config files under /etc between the two hosts and, other
> than some minor, unrelated host-specific differences, everything is
> identical, including configs under /etc/pam.d.
>
> I can get it to kind of work with a blank password, but that's not the
> point and is not a viable "solution". Even then, it still doesn't auto
> open, but at least it doesn't produce annoying prompts to open.
>
> I've always despised KWallet for its flaky behaviour but for the last
> few years it hadn't given me any issues up until now.
>
> I'm truly bewildered. Is there anything I am missing?

Are you testing with LightDM and SDDM logins where you type your
password manually, rather than relying on autologin, or fingerprint
readers, etc.? If memory serves me, something needs to pass down the
password to kwallet, so with autologin, it can't unlock the wallet.
(At least, not without extra help, I see the Arch wiki mentions
pam_autologin for this but I haven't used it: [1])

Hope this helps, but it's been a while since I've used the wallet.

[1] https://wiki.archlinux.org/title/KDE_Wallet#Unlock_KDE_Wallet_automatically_on_login

- Bryan

On Sunday, 11 June 2023 23:48:08 BST Victor Ivanov wrote:
> On Sun, 11 Jun 2023 at 14:22, Neil Bothwick <neil@digimed.co.uk> wrote:
> > Anything in the logs? Maybe someting to indicate whether PAM is trying to
> > open the wallet and failing, or whether it is not trying at all.
>
> Thanks, Neil, good point. Not that I can tell. /var/log/auth.log looks
> identical on both systems after cold boot login. Here's an example
> (same on both hosts):
>
> ---
> Jun 11 23:13:04 somehost sddm-helper: pam_unix(sddm-greeter:session):
> session opened for user sddm(uid=****) by (uid=0)
> Jun 11 23:13:06 somehost start-stop-daemon:
> pam_unix(start-stop-daemon:session): session opened for user
> pcscd(uid=(uid=****) by (uid=0)
> Jun 11 23:13:15 somehost sddm-helper: gkr-pam: unable to locate daemon
> control file
> Jun 11 23:13:15 somehost sddm-helper: gkr-pam: stashed password to try
> later in open session
> Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:auth):
> pam_kwallet5: pam_sm_authenticate
> Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:setcred):
> pam_kwallet5: pam_sm_setcred
> Jun 11 23:13:15 somehost sddm-helper: pam_unix(sddm:session): session
> opened for user *****(uid=*****) by (uid=0)
> Jun 11 23:13:15 somehost sddm-helper: gkr-pam: gnome-keyring-daemon
> started properly and unlocked keyring
> Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:session):
> pam_kwallet5: pam_sm_open_session
> Jun 11 23:13:15 somehost sddm-helper: pam_kwallet5(sddm:setcred):
> pam_kwallet5: pam_sm_setcred
> Jun 11 23:13:17 somehost gnome-keyring-daemon[5636]: discover_other_daemon:
> 1 Jun 11 23:13:17 somehost polkitd[3881]: Registered Authentication
> Agent for unix-session:2 (system bus name :1.48
> [/usr/lib64/libexec/polkit-kde-authentication-agent-1], object path
> /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.utf8)
> ---
>
> So it would appear "pam_kwalletd5" is loaded and initialised. There
> are no errors It makes me wonder if gnome keyring is to blame and if
> there's some sort of a race condition. On the other hand, there is the
> message "discover_other_daemon: 1".

I have seen the same in one of my systems. I understand the gkr message to be
informational only, after all it succeeds once kwallet5 kicks in.


> Besides, if it were a race I would
> expect KWallet to work at least some of the time on either system,
> while the issue is always reproducible on one host and never on the
> other.

Yes, or at least it would be logical to expect some error message if a race
condition occurred and gnome keyring failed to authenticate.


> Other logs such as "/var/log/sddm.log" and
> "$HOME/.local/share/sddm/wayland-session.log" also look similar on
> both hosts without anything related to KWallet.
>
> I've also one-shot "eix -I# sddm" (SDDM owns sddm-helper) with
> --noconfmem. Still no luck. Use flags are more or less identical on
> both hosts as well.
>
> Something is tricksing me badly and I'm one step from emerging @world
> with --noconfmem and --empytree to see if that helps.

You could try making gnome keyring wait until a login session is up an running
and only run if an application asks for it. Take a look in /etc/pam.d/sddm
(or perhaps /etc/pam.d/sddm-autologin?) then add an 'only_if' conditional
statement at the end, e.g.:

-session optional pam_gnome_keyring.so only_if=gdm,sddm,xdm,<add any other DM
here>

This means whenever an application requires gnome keyring it will ask you for
your passwd, instead of auto-unlocking it at the start of the desktop login
session. However, this may or may not fix your problem, because as you point
out the other host is working normally without this tweak. I wonder ... is
the other host running on (much) slower hardware?

On Mon, 12 Jun 2023 at 06:53, Bryan Gardiner <bog@khumba.net> wrote:
> Are you testing with LightDM and SDDM logins where you type your
> password manually, rather than relying on autologin, or fingerprint
> readers, etc.? If memory serves me, something needs to pass down the
> password to kwallet, so with autologin, it can't unlock the wallet.
> (At least, not without extra help, I see the Arch wiki mentions
> pam_autologin for this but I haven't used it: [1])
>
Yes, I never use auto login. It's password based SDDM set up.

Configs are in line with suggestions in Gentoo Wiki. I too consulted
the Arch Wiki but most of it overlaps (as one might expect). To be
honest, these days the kde-plasma/kwallet-pam package comes with the
correct config by default and I've not had to touch it manually.

On Mon, 12 Jun 2023 at 09:33, Michael <confabulate@kintzios.com> wrote:
>
> You could try making gnome keyring wait until a login session is up an running
> and only run if an application asks for it. Take a look in /etc/pam.d/sddm
> (or perhaps /etc/pam.d/sddm-autologin?) then add an 'only_if' conditional
> statement at the end, e.g.:
>
> -session optional pam_gnome_keyring.so only_if=gdm,sddm,xdm,<add any other DM
> here>
>
> This means whenever an application requires gnome keyring it will ask you for
> your passwd, instead of auto-unlocking it at the start of the desktop login
> session. However, this may or may not fix your problem, because as you point
> out the other host is working normally without this tweak.
>
Interesting suggestion, thanks! I tried this, as well as adding force_run to
"-session optional pam_kwallet5.so auto_start"
neither option worked.

> out the other host is working normally without this tweak. I wonder ... is
> the other host running on (much) slower hardware?
>
Yes and no. They're both Skylake machines with mobile CPUs, only
difference is the one it's not working on is a quad-core i7 HQ series
and the other (where it's working) is a dual-core i7 U-series low
voltage.

On the other hand, I decided to F it, and move back to Xorg. It all
works fine on Xorg after the usual wipe of KDE-related stuff in
~/.config, ~/.local, and ~/.cache. Trying a Wayland session _after_
the fact, is still broken. Yet, I can't see anything in the logs to
suggest why this might be the case.

This, on top of Night Colour also not work well (gets stuck in
whatever state it was in if the display goes to sleep) tells me
Wayland is _still_ not ready for day to day use. Which is a shame,
because it's _this_ close, but annoyances like the above are just not
worth the hassle (yet).

Ironically, the timing of my post is near perfect with that of the
other thread re Wayland issues.

Best Regards,
Victor