Bug 1796544

Summary: gkr-pam: unable to locate daemon control file
Product: [Fedora] Fedora Reporter: Gabriel Zilio <gabriel.dambrosio1>
Component: gdmAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 31CC: axel+fedora, caillon+fedoraproject, forlorn, gabriel.dambrosio1, gnome-sig, john.j5live, mclasen, mike, mike, normand, philip.wyett, prateek.1.kohli, prd-fedora, rhughes, rstrode, thomas, william, yannik.zausig
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-24 18:40:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Journalctl of gdm.service with gkr-pam error
none
journalctl -b with relevant data none

Description Gabriel Zilio 2020-01-30 16:50:44 UTC
Description of problem:

After install Fedora 31 Workstation, in Logs, reproduce this red message in gdm-password: gkr-pam: unable to locate daemon control file. 

Version-Release number of selected component (if applicable): GDM 3.34.1


How reproducible:


Steps to Reproduce:
1. Open Terminal
2. Execute: journalctl --unit gdm.service -f

Actual results:

Jan 30 12:28:55 zilione systemd[1]: Starting GNOME Display Manager...
Jan 30 12:28:55 zilione systemd[1]: Started GNOME Display Manager.
Jan 30 12:31:51 zilione gdm-password][1375]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost=  user=zilion
Jan 30 12:31:51 zilione gdm-password][1375]: gkr-pam: unable to locate daemon control file
Jan 30 12:32:03 zilione gdm-password][1385]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost=  user=zilion
Jan 30 12:32:03 zilione gdm-password][1385]: gkr-pam: unable to locate daemon control file
Jan 30 12:32:14 zilione gdm-password][1391]: gkr-pam: unable to locate daemon control file


Expected results:

Repair this file and find the daemon.


Additional info: Fedora 31 Workstation (with Gnome 3.34.1). Not modified.

Comment 1 Yannik 2020-03-02 18:48:08 UTC
Created attachment 1667044 [details]
Journalctl of gdm.service with gkr-pam error

Comment 2 Yannik 2020-03-02 18:53:38 UTC
I've addded an attachment showing the same gkr-pam error, but with different overall behaviour. In my case, the error appears already in gdm.service and prevents a successful login using GNOME Desktop on Fedora 31 Workstation.

Behaviour of this login loop is: GNOME login shell appears > select account and enter password > password is correct, but screen turns gray, then black > GNOME login shell reappears.

I hope this is also relevant for this bug; if not, just hit me up and I'll file a separate bug report for it

Comment 3 Paul DeStefano 2020-05-01 21:23:27 UTC
Hmm, I can login fine, but I get this error, too.

I cannot seem to lock the screen, though, so I found this while I was researching that problem.

Comment 4 William 2020-05-03 17:20:05 UTC
"upgraded" to fedora 32 on the 1st of May.   Just noticed this error for the first time today in the Logs application.   Not sure if its been happening or not.    (noticed after a reboot)


journalctl --unit gdm.service -f
-- Logs begin at Thu 2020-03-12 19:13:36 EDT. --
May 03 13:09:52 fedora systemd[1]: Stopping GNOME Display Manager...
May 03 13:09:53 fedora gdm[1716]: GdmLocalDisplayFactory: Failed to issue method call: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected
May 03 13:09:53 fedora gdm[1716]: Freeing conversation 'gdm-password' with active job
May 03 13:09:53 fedora systemd[1]: gdm.service: Succeeded.
May 03 13:09:53 fedora systemd[1]: Stopped GNOME Display Manager.
-- Reboot --
May 03 13:11:11 fedora systemd[1]: Starting GNOME Display Manager...
May 03 13:11:11 fedora systemd[1]: Started GNOME Display Manager.
May 03 13:11:23 fedora gdm-password][2556]: gkr-pam: unable to locate daemon control file
May 03 13:11:23 fedora gdm-password][2556]: gkr-pam: stashed password to try later in open session
May 03 13:11:27 fedora gdm[1829]: Child process -2027 was already dead.

Comment 5 Forlorn 2020-05-09 20:29:08 UTC
Error appeared after upgrading to F32 on both Fedora PCs.

Comment 6 mike 2020-05-29 19:25:32 UTC
Created attachment 1693520 [details]
journalctl -b with relevant data

Since yesterday I cannot log into Fedora 32 with an Active Directory account. Reinstalled from disk (Fedora-Workstation-Live-x86_64-32-1.6.iso) while preserving /home partition, used realm join again and still unable to log in under a network account. Also tried another account which had not previously logged in and get similar failure.

Seeing Access denied ... 4 (System error) in the journal:

May 29 12:39:26 my-hostname gdm-password][3982]: pam_sss(gdm-password:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=my_ad_user
May 29 12:39:26 my-hostname audit[3982]: USER_AUTH pid=3982 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_usertype,pam_usertype,pam_sss,pam_gnome_keyring acct="my_ad_user" exe="/usr/libexec/gdm-session-worker" hostname=my-hostname addr=? terminal=/dev/tty1 res=success'
May 29 12:39:26 my-hostname gdm-password][3982]: gkr-pam: unable to locate daemon control file
May 29 12:39:26 my-hostname gdm-password][3982]: gkr-pam: stashed password to try later in open session
May 29 12:39:26 my-hostname gdm-password][3982]: pam_sss(gdm-password:account): Access denied for user my_ad_user: 4 (System error)
May 29 12:39:26 my-hostname audit[3982]: USER_ACCT pid=3982 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=? acct="my_ad_user" exe="/usr/libexec/gdm-session-worker" hostname=my-hostname addr=? terminal=/dev/tty1 res=failed'
May 29 12:39:26 my-hostname audit[3982]: USER_LOGIN pid=3982 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=27129 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=failed'

Local user logs in fine.

Another interesting behavior is that when I am logged in under the "my_local_user" account and I use the "Switch User" feature, I attempt to log into the "my_ad_user" account and fail (errors above), then I log back in as "my_local_user" again, successfully, but ten seconds later the screen locks. I unlock with my password again and it doesn't happen again unless I use the "Switch User" feature again.

Comment 7 Thomas Höll 2020-06-11 08:37:11 UTC
I guess was this is somehow related to https://github.com/systemd/systemd/issues/15149. When I login on a console, I get an error from pam_systemd:

Jun 11 10:33:10 my-hostname login[6639]: pam_sss(login:auth): authentication success; logname=LOGIN uid=0 euid=0 tty=tty3 ruser= rhost= user=my-ad-user
Jun 11 10:33:10 my-hostname audit[6639]: USER_AUTH pid=6639 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_usertype,pam_usertype,pam_sss acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:10 my-hostname audit[6639]: USER_ACCT pid=6639 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname audit[6639]: CRED_ACQ pid=6639 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_localuser,pam_sss acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname login[6639]: pam_systemd(login:session): Failed to get user record: No such proces
Jun 11 10:33:11 my-hostname login[6639]: pam_unix(login:session): session opened for user my-ad-user by LOGIN(uid=0)
Jun 11 10:33:11 my-hostname audit[6639]: USER_START pid=6639 uid=0 auid=1753801108 ses=5 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_unix,pam_umask,pam_lastlog acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname audit[6639]: CRED_REFR pid=6639 uid=0 auid=1753801108 ses=5 msg='op=PAM:setcred grantors=pam_localuser,pam_sss acct="my-ad-user" exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname audit[6639]: USER_LOGIN pid=6639 uid=0 auid=1753801108 ses=5 msg='op=login id=1753801108 exe="/usr/bin/login" hostname=my-hostname addr=? terminal=tty3 res=success'
Jun 11 10:33:11 my-hostname login[6639]: LOGIN ON tty3 BY my-ad-user@my-ad-domain


Note: I already upgraded to systemd from rawhide

Comment 8 Thomas Höll 2020-06-11 08:43:34 UTC
I forgot to mention that I tried upgrading to pam from rawhide, same behaviour.

Comment 9 Ben Cotton 2020-11-03 17:15:27 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 10 Ben Cotton 2020-11-24 18:40:13 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 11 Michael Vorburger.ch 2020-12-23 21:38:21 UTC
FYI new related Bug 1893131 created.

Comment 12 axel 2023-05-17 12:10:34 UTC
This bug is still present in Fedora 37 and 38. I'd been hitting it for a while on F37, and the only way to log in was to first run `gnome-session --failsafe` in a TTY before logging in in GDM.
I thought i'd fixed it with `sudo iptables -I INPUT -i lo -j ACCEPT` which as weird as it seemed, appeared to have worked.

I then upgraded to F38. And today, after runnning a dnf upgrade and rebooting to get the latest kernel, i am back to this issue: impossible to log in to GNOME and after entering credentials, i get dropped back to the GDM screen.
Removing gnome-shell extensions in case one of them is problematic makes no difference. Again, only `gnome-session --failsafe` allows me to log in. 

(In reply to Michael Vorburger.ch from comment #11)
> FYI new related Bug 1893131 created.

Bug 1893131 is completely unrelated: "gpg + yubikey is broken in Fedora Silverblue"

Is there a follow up bug?