Summary: | x11-misc/lightdm: does not unlock gnome-keyring on login | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gregory Beauregard <gentoobugs> |
Component: | Current packages | Assignee: | Lars Wendler (Polynomial-C) (RETIRED) <polynomial-c> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | sam, zlogene |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
system log when keyring unlock was working
system log when it's broke working log up until unlock success fail log up until unlock failure |
Description
Gregory Beauregard
2020-10-10 16:09:21 UTC
please provide journalctl -f or any equivalent file containing logged information about failed attempts (pam logs what it does) Created attachment 664549 [details]
system log when keyring unlock was working
Created attachment 664552 [details]
system log when it's broke
So for context, I have this in my .zshrc to allow the ssh autologin: if [ -n "$DESKTOP_SESSION" ];then eval $(gnome-keyring-daemon --start) export SSH_AUTH_SOCK fi (see e.g. arch wiki) I ran two commands: sudo journalctl -b -2 -a --no-pager | grep -m 200 -i 'lightdm\|pam\|keyring\|gcr' > working.txt sudo journalctl -b -a --no-pager | grep -m 200 -i 'lightdm\|pam\|keyring\|gcr' > broke.txt to hopefully filter out as much as possible to the changed stuff. I'm looking through them now as well. Please let me know if it's missing something you need. There's new gcr log file stuff that wasn't there before, but I hadn't set (or needed to set) +gnome-keyring USE flag on pambase before so that could where it's coming from. I was hoping if indeed the change is coming from pam/pambase (as it was one of the few updated packages) you would have an idea what changed. I'm still trying to explore to see if there's other additional info I can find so feel free to let me know or contact me in freenode #gentoo (I'm aphysically) Not sure it is strictly pam relevant: 1.) sys-libs/pam does not ship gnome-keyring module at all. 2.) what pambase is using is shipped by the gnome-base/gnome-keyring package 3.) there were no changes made to the stack other than making gnome-keyring an optional module for pambase (it is literally just means adding 'if' conditions, so nothing really drastic) What version of gnome keyring are you using? I have gnome-base/gnome-keyring-3.36.0 you can see the difference fairly early in boot from the older working Oct 07 23:37:17 ares lightdm[2790]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring to the newer Oct 10 11:17:39 ares lightdm[2735]: gkr-pam: gnome-keyring-daemon started properly I'm trying right now to look through the more complete logs to try to see if there's something else relevant I can find. If you think it's worth it I can try the older package to A/B test if it's really pambase if you re-add it to tree. Although, given the change was gnome-keyring related it does seem like less of a coincidence. What I see from the logs where pam-gcr stopped working for you is: /usr/bin/ssh-add command failed: Child process exited with code 1 Which might be relevant. Just to be sure, could you try to log-in without lightdm and then try using startx? I do not except the case where lightdm's pam stack might be involved (but unlikely it is the case), and then see logs again? Also, as far as I understand you are using gnome-keyring as a mean of ssh pass unlock right? Do not you happen to have something other than keyring for that? Say, pam_ssh? (FWIW, I’m about to head to bed here but I agree with Mikle’s analysis right now. It’s be a hell of a coincidence but I don’t think we changed anything related.) Created attachment 664561 [details]
working log up until unlock success
Created attachment 664564 [details]
fail log up until unlock failure
I hadn't thought the ssh-add command failure was especially important since it occurred after the first obvious failure deviation (i.e. it had already failed to say "and unlocked keyring". I grabbed the 500 lines of system log from everything leading up until where it first states it either does/doesn't unlock keyring in the working and non-working system log. I don't think I have it configured to unlock if I login without lightdm: my main reason for using gnome-keyring was to get the keyring to automatically unlock when I logged in with my display manager. You can find on the gentoo-wiki for lightdm where you add the appropriate pam stuff to lgihtdm in summary, you: in /etc/pam.d/lightdm: Add auth optional pam_gnome_keyring.so at the end of the auth section and session optional pam_gnome_keyring.so auto_start at the end of the session section I think there are ways to get auto unlock outside of that as well, but I haven't tried them. Do you want me to look into trying to get a different auto unlock to work? My last lightdm compile was 08/05/2020. To be perfectly clear (I realize I could have been clearer before): gnome-keyring does display a password prompt for an ssh key when I, say, try to ssh into a box where I have a key stored in my keyring. The issue is that the gnome-keyring should have been automatically unlocked by lightdm via pam, and that's what stopped working for me. but if you modify /etc/pam.d/lightdm it is not pam at all (itself). I mean yes, it is releated to the stack, but it is not pam/pambase causing it. But I am wondering, can you please try to change all the `include` lines to the `substack` ones here: https://gitweb.gentoo.org/repo/gentoo.git/tree/x11-misc/lightdm/files/lightdm-autologin (well, it is the /etc/pam.d/lightdm file actually), and try again? I think some (most?) displaymanagers ship this config/behavior by default (I think lightdm is supposed to be one of them at least according to arch-wiki, but for whatever reason it required adding the modification in Gentoo. Not sure if the wiki is wrong or one of arch/gentoo change default behavior) Do you think it's relatively certain the recent pam/pambase changes didn't trigger the problem (like, say, that some change could have triggered a bug in lightdm's handling of some new behavior)? I'm going to try this include suggestion, but first I will boot into the new pambase you released to isolate what change at a time. I'll get back to you shortly. Changing all of the 'include' in /etc/pam.d/lightdm to 'substack' resulted in the autounlock working as expected. The file now looks like: auth substack system-local-login auth optional pam_gnome_keyring.so account substack system-local-login password substack system-local-login session substack system-local-login session optional pam_gnome_keyring.so auto_start Can you provide any insight on what this did and why it could have been suddenly needed? Is this a change I want to keep around? Is this something lightdm needs to change and perhaps other DMs in gentoo as well? (In reply to Gregory Beauregard from comment #16) > I think some (most?) displaymanagers ship this config/behavior by default (I > think lightdm is supposed to be one of them at least according to arch-wiki, > but for whatever reason it required adding the modification in Gentoo. Not > sure if the wiki is wrong or one of arch/gentoo change default behavior) Very often distros have to ship theIr own pam stack files, what upstream ships often does not fit in practice, so we ship our own config (so does Arch). > [snip] The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=78187c218bcde260ef8ff50ddb3e3c34db5cb55f commit 78187c218bcde260ef8ff50ddb3e3c34db5cb55f Author: Mikle Kolyada <zlogene@gentoo.org> AuthorDate: 2020-10-11 06:58:21 +0000 Commit: Mikle Kolyada <zlogene@gentoo.org> CommitDate: 2020-10-11 06:58:21 +0000 x11-misc/lightdm: include ⟶ substack pambase files Acked-by: Lars Wendler <polynomial-c@gentoo.org> Closes: https://bugs.gentoo.org/747625 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Mikle Kolyada <zlogene@gentoo.org> x11-misc/lightdm/files/lightdm-autologin | 4 ++-- .../lightdm/{lightdm-1.30.0-r1.ebuild => lightdm-1.30.0-r2.ebuild} | 0 2 files changed, 2 insertions(+), 2 deletions(-) |