Bug 26898 - [M8a1]gkr-pam: unable to locate daemon control file
Summary: [M8a1]gkr-pam: unable to locate daemon control file
Status: ASSIGNED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: release_blocker normal
Target Milestone: ---
Assignee: GNOME maintainers
QA Contact:
URL:
Whiteboard:
Keywords: Triaged
Depends on:
Blocks:
 
Reported: 2020-07-05 13:11 CEST by Pierre Opter
Modified: 2020-07-30 11:16 CEST (History)
4 users (show)

See Also:
Source RPM:
CVE:
Status comment: Should align PAM with Fedora. Needs discussion on dev mailing list


Attachments
journalctl -b -p err command (84.83 KB, image/png)
2020-07-06 22:49 CEST, Pierre Opter
Details

Description Pierre Opter 2020-07-05 13:11:04 CEST
Description of problem under Gnome:
At first view, i saw nothing when i switch on my computer (a laptop clevo base).
But when i do this command: journalctl -b -p err
i have this error : gkr-pam: unable to locate daemon control file
 

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


How reproducible: I'm on a very fresh install. Just switch on the PC and pass the upon command.


Steps to Reproduce:
1. 
2.
3.
papoteur 2020-07-05 18:48:17 CEST

CC: (none) => yves.brungard_mageia
Summary: gkr-pam: unable to locate daemon control file => [M8a1]gkr-pam: unable to locate daemon control file

Comment 1 papoteur 2020-07-05 19:15:34 CEST
gkr-pam means pam_gnome_keyring
Comment 2 Lewis Smith 2020-07-06 20:35:28 CEST
@Pierre
Can you please say something about your system, and how you installed Mageia. Is Gnome the only desktop you have?

> i saw nothing when i switch on my computer
How are you able to do the journalctl command?

CC: (none) => lewyssmith

Comment 3 Pierre Opter 2020-07-06 22:49:25 CEST
Created attachment 11735 [details]
journalctl -b -p err command
Comment 4 Pierre Opter 2020-07-06 22:52:14 CEST
Yes Gnome is the only desktop installed on my laptop.
; 
But i am not sure to understand very well your second question....but sorry for my poor english :-(
Saw the screenshot above.

Thanks a lot
Comment 5 papoteur 2020-07-07 07:20:09 CEST
To be clear, Pierre has a working desktop. He saw the error in the journal after the start by inspection.
Comment 6 Aurelien Oudelet 2020-07-07 22:12:46 CEST
Hi, it is upstream bug: https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/28

According to this comment:
"ettavolt @ettavolt ยท 6 months ago

This morning I've been reading pam_gnome_keyring sources to understand the cause of a race condition between keyring unlocking during autologin and systemd user service 'softu2f token'.

Looks like, one such message is a must for a login without a session already running. It's not printed if unlocking after a screen lock (I see only an informational one "gkr-pam: unlocked login keyring").

This log line indicates that during auth step pam_gnome_keyring.so pam entry had a proper password string, it tried to unlock keyring, but some environment variables were missing, and module decided to retry during session phase.

I guess, it may be worth adding some LOG_INFOs in the ifs branches after unlock_keyring calls to indicate what pam_gnome_keyring is going to do about the warned condition."

There is a commit there and available in gnome-keyring-3.36 package.
Therefore, race condition is still present.

CC: (none) => ouaurelien

Comment 7 Aurelien Oudelet 2020-07-29 22:53:18 CEST
Upstream recommends:
https://wiki.gnome.org/Projects/GnomeKeyring/RunningDaemon

Starting Gnome Keyring Daemon

    The best place to start gnome-keyring-daemon is from the user's login. This is done via a PAM module. When configured correctly the user does not need to enter any passwords beyond that of their login.
    In addition gnome-keyring-daemon must be initialized from the session startup. Usually this is accomplished by the autostart desktop files that gnome-keyring-daemon installs.
    If gnome keyring was not started from the PAM module, the autostart desktop files will start a gnome-keyring-daemon properly. In this case the user will need to specify an unlock password for their keyring on its first use.
    If your PAM configuration allows you to log in without entering a password (e.g. via smart card or fingerprint), you will also need to specify an unlock password for your keyring on its first use.
    If not started by one of the above, it will be automatically activated by DBus for basic password operations. However much functionality will not be available, such as the SSH agent and encryption key store. 

https://wiki.gnome.org/Projects/GnomeKeyring/Pam

Upstream remarks of "some environment variables missing". What about in our config files.

Passing to Gnome maintainers.

Assignee: bugsquad => gnome
Status: NEW => ASSIGNED
Keywords: (none) => Triaged

Comment 8 Olav Vitters 2020-07-30 11:16:45 CEST
Our pam config seems somewhat ok. I do see some differences with what Fedora does. There's also a bug when autologin is used with GDM. Maybe best to just switch the PAM method over to what Fedora does. This will mean packaging authselect and switching over. From reading the PAM spec history on Fedora, it seems our config is quite out of date and ancient.

Status comment: (none) => Should align PAM with Fedora. Needs discussion on dev mailing list
CC: (none) => olav
Priority: Normal => release_blocker


Note You need to log in before you can comment on or make changes to this bug.