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"
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.
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.
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 ) instead of usual ilgaz , 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?
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?
Created attachment 1719424 [details] goa debug
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?
(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.
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).
+4 votes in the ticket, marking accepted blocker.
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?
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.
(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
Moving the blocker back to proposed state on Michael's request: https://pagure.io/fedora-qa/blocker-review/issue/142#comment-695108
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?
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
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.
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.
>> 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.
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
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.
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.
Is there a known workaround for this behaviour? Thanks.
(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.
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.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. 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 '33'. 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 33 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.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 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.