Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1885479 - Keyring remains locked after autologin, or after changing the user's password with passwd
Summary: Keyring remains locked after autologin, or after changing the user's password...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-keyring
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker https://fedoraproject...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-06 05:50 UTC by Chris Murphy
Modified: 2021-04-29 21:53 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
screenshot (31.82 KB, image/png)
2020-10-06 05:50 UTC, Chris Murphy
no flags Details
journal (801.91 KB, text/plain)
2020-10-06 05:53 UTC, Chris Murphy
no flags Details
goa debug (17.86 KB, text/plain)
2020-10-06 14:35 UTC, Chris Murphy
no flags Details
Debug output while having the issue (26.03 KB, text/plain)
2020-10-10 18:58 UTC, Ilgaz
no flags Details

Description Chris Murphy 2020-10-06 05:50:44 UTC
Created attachment 1719247 [details]
screenshot

Description of problem:

Immediately after authenticating, I'm informed credentials have expired.


Version-Release number of selected component (if applicable):
gnome-online-accounts-3.37.90-1.fc33.x86_64
gnome-shell-3.38.1-1.fc33.x86_64
selinux-policy-3.14.6-28.fc33.noarch


How reproducible:
Always


Steps to Reproduce:
1. Online accounts > Google
2. Enter password and confirm 2 factor
3. Click Allow (access to all listed items)

Actual results:

It seems to accept it; but then I see ⚠ (warning sign) next to the account. Click on the account and I see that credentials have expired (see screenshot).


Expected results:

I should have access to my Google account within GNOME.


Additional info:

I have a notification on my phone "GNOME was granted access to your Google account"

Comment 1 Chris Murphy 2020-10-06 05:53:08 UTC
Created attachment 1719248 [details]
journal

The first time this failed, there are goa messages. But even after logging out and back in and trying again, following the journal while trying to enable the account didn't show anything interesting/relevant.

Comment 2 Fedora Blocker Bugs Application 2020-10-06 05:57:14 UTC
Proposed as a Blocker for 33-final by Fedora user chrismurphy using the blocker tracking app because:

 https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#First_boot_experience

If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test.

Comment 3 Ilgaz 2020-10-06 09:47:51 UTC
I also have 2FA  enabled and I have the same issue. However, if I "remove account" (red button) from the prompt where it says credentials have expired and use the gmail address associated with my account (ilgaz.nsa@gmail.com ) instead of usual ilgaz@fastmail.fm , second try, a superuser request window appears (for root) and it adds account fine. I have checked via browsing google drive files from file explorer. Could it be related to using something other than gmail while logging in?

Comment 4 Debarshi Ray 2020-10-06 13:35:51 UTC
There are some tips on how to debug GNOME Online Accounts problems:
https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Debugging

Does it help you dig up some more data?

Comment 5 Chris Murphy 2020-10-06 14:35:47 UTC
Created attachment 1719424 [details]
goa debug

Comment 6 Debarshi Ray 2020-10-09 15:26:16 UTC
Thanks for that debug log, Chris.

These lines stand out:

** INFO: 08:32:46.042: Remote error from secret service: org.freedesktop.Secret.Error.IsLocked: Cannot create an item in a locked collection

(goa-daemon:3047): GoaBackend-WARNING **: 08:32:46.042: secret_password_store_sync() failed: Cannot create an item in a locked collection

It means that your Google access token didn't actually get written to gnome-keyring, which explains the subsequent behaviour.

I wonder if your keyring broke somehow. Did you happen to change the password of your user account?

Comment 7 Ilgaz 2020-10-09 18:20:54 UTC
(In reply to Debarshi Ray from comment #6)
> Thanks for that debug log, Chris.
> 
> These lines stand out:
<snip>
> I wonder if your keyring broke somehow. Did you happen to change the
> password of your user account?

You didn't ask to me but I wonder if it does have anything to do with autologin enabled? I have it enabled.

Comment 8 Chris Murphy 2020-10-09 22:28:39 UTC
1. Brand new clean account: problem doesn't happen.
2. Settings>Users> change password for this user, log out and back in: problem doesn't happen
3. Command line 'passwd' command to change the password for the user, log out and back in; problem does happen.

My vague recollection is with the original reported problem, I did change the password post-install using the passwd command. I guess Users panel updates the password in a different way than the passwd CLI command, in which case I'd argue this bug is not a blocker bug, but conditional due to a specific local configuration difference (using CLI instead of the GUI to change the password).

Comment 9 Adam Williamson 2020-10-09 22:56:52 UTC
+4 votes in the ticket, marking accepted blocker.

Comment 10 Michael Catanzaro 2020-10-10 13:55:54 UTC
Could there be a problem with the gnome-keyring PAM module? Changing password with passwd is supposed to update the keyring password.

Even if the keyring is locked, gnome-keyring should prompt the user to unlock it. That might be https://gitlab.gnome.org/GNOME/libsecret/-/issues/7 though, a longstanding issue.

Is it possible for gnome-online-accounts to fail with a better error instead of this confusing error?

Comment 11 Ilgaz 2020-10-10 18:58:28 UTC
Created attachment 1720461 [details]
Debug output while having the issue

I carried the instructions at Gnome Wiki, sorry for console output I am in hurry.

Comment 12 Kamil Páral 2020-10-12 08:47:56 UTC
(In reply to Adam Williamson from comment #9)
> +4 votes in the ticket, marking accepted blocker.

Ticket link:
https://pagure.io/fedora-qa/blocker-review/issue/142

Comment 13 Kamil Páral 2020-10-12 08:54:19 UTC
Moving the blocker back to proposed state on Michael's request:
https://pagure.io/fedora-qa/blocker-review/issue/142#comment-695108

Comment 14 Adam Williamson 2020-10-12 17:22:34 UTC
Michael, Debarshi - any thoughts on Ilgaz's case? It seems to have the same error message, but he says he has not changed his password with passwd. Could autologin be the issue in his case?

Comment 15 Michael Catanzaro 2020-10-12 17:33:10 UTC
Maybe.

If you have autologin enabled, the keyring is going to be locked upon login unless you have a LUKS password configured and your LUKS password matches your user account password. However, I believe libsecret should still unlock the keyring automatically for you when it is needed by gnome-online-accounts, by prompting you to enter your password.

Similarly, passwd should invoke gnome-keyring's PAM module to change your keyring password when you change your password.

I think there are actually two bugs here:

 1. This bug: keyring is not properly unlocked, possibly libsecret#7. Requires investigation by libsecret and/or gnome-online-accounts developers.
 2. passwd/PAM bug: keyring password not updated for some reason, requires a separate bug report

Comment 16 Ilgaz 2020-10-12 17:39:15 UTC
I had autologin enabled and disabling autologin, rebooting and using password to enter my account and adding Google account again worked. It must be autologin related. I enabled autologin in installation stage.

Comment 17 Michael Catanzaro 2020-10-12 18:21:26 UTC
It looks like libsecret unlocks the keyring if you call secret_service_search() with SECRET_SEARCH_UNLOCK, and not otherwise. But gnome-online-accounts doesn't use secret_service_search() at all; it uses secret_password_lookup_sync(). And I don't see any documentation to indicate how that function is intended to behave. I *hope* it's supposed to unlock the keyring, but maybe not?

These seems likely to be a longstanding bug rather than an F33 regression.

Comment 18 Debarshi Ray 2020-10-12 19:15:26 UTC
>> with the original reported problem, I did change the
>> password post-install using the passwd command. I guess
>> Users panel updates the password in a different way
>> than the passwd CLI command
>
> Could there be a problem with the gnome-keyring PAM module?
> Changing password with passwd is supposed to update the
> keyring password.

Halfline pointed me to pam_gnome_keyring.so inside /etc/pam.d/passwd, so it seems that passwd(1) is meant to update the gnome-keyring password as well.

Comment 19 Geoffrey Marr 2020-10-12 19:29:37 UTC
Discussed during the 2020-10-12 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" was made as it only happens when the user password is changed in a certain way (that is fairly unlikely to be encountered on first boot or in live usage).

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-10-12/f33-blocker-review.2020-10-12-16.00.txt

Comment 20 Adam Williamson 2020-10-12 21:47:18 UTC
So to summarize the state of play here is basically this:

If you in any way wind up in a desktop session with the login keyring locked - which can happen in various ways, two of which we've discussed - then try to authenticate to an online account which requires writing a token to the keyring, you should be prompted to unlock it, but you aren't, the operation just fails.

I agree with mcatanzaro in #c15 that we should separate "updating password with passwd does not update the login keyring password" into another bug.

Comment 21 Adam Williamson 2020-10-12 21:48:04 UTC
I think I'm still -1 blocker on this even with the note that there are other triggers for the bug (autologin being one), FWIW.

Comment 22 Lukas Ruzicka 2020-10-26 14:46:52 UTC
Is there a known workaround for this behaviour? Thanks.

Comment 23 Debarshi Ray 2020-10-26 15:59:54 UTC
(In reply to Lukas Ruzicka from comment #22)
> Is there a known workaround for this behaviour? Thanks.

It's possible to change the GNOME Keyring password from an application like Seahorse. The "Passwords" section lists all the keyrings. It's possible to right-click each keyring and change the password.

Comment 24 Debarshi Ray 2021-04-16 21:21:57 UTC
Reassigning to gnome-keyring because this is ultimately about the keyring not getting unlocked during autologin or when the user's password has been changed with passwd.


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