GNOME Bugzilla – Bug 738714
If online account is configured in g-i-s user creation mode, user's keyring password is broken and can never be accessed
Last modified: 2014-10-21 17:09:57 UTC
I'm not quite sure exactly how to describe this best or precisely what's breaking, but it seems like a bad bug. It's 100% reproducible for me with Fedora 21 Beta TC3 Workstation x86_64 as follows: 1. Boot and install, setting a root password but creating no user, with Canada as the location 2. On booted system, run through g-i-s, selecting English (Canada) as the keyboard layout (I don't think the location/layout matter, but stating it for comprehensiveness) 3. Create a user acount 'test' with password 'test' or 'correcthorse01' 4. Configure an ownCloud account when offered the chance 5. Complete g-i-s and wait for the desktop to appear What happens is that the dialog "Enter password to unlock your login keyring - The password you use to log in to your computer no longer matches that of your login keyring." appears. Entering the password you set in g-i-s produces "The unlock password was incorrect". I've found no password that makes it happy; all you can do is hit Cancel. This persists on a reboot; it seems the user's keyring is just permanently broken if you do this. The journal output has several errors about keyring stuff: Oct 17 11:51:16 localhost.localdomain gnome-session[1102]: ** (gnome-initial-setup:1256): WARNING **: Failed to change keyring password: GDBus.Error:org.gnome.keyring.Error.Denied: The password was invalid Oct 17 11:51:19 localhost.localdomain gnome-keyring-daemon[1526]: failed to unlock login keyring on startup Oct 17 11:51:19 localhost.localdomain gnome-session[1568]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Oct 17 11:51:19 localhost.localdomain gnome-session[1568]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Oct 17 11:51:19 localhost.localdomain gnome-session[1568]: GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1 Oct 17 11:51:19 localhost.localdomain gnome-session[1568]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Oct 17 11:51:19 localhost.localdomain gnome-session[1568]: GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1 Oct 17 11:51:19 localhost.localdomain gnome-session[1568]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Oct 17 11:51:19 localhost.localdomain gnome-session[1568]: GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1 Oct 17 11:57:17 localhost.localdomain org.gnome.OnlineAccounts[1581]: goa-daemon-Message: /org/gnome/OnlineAccounts/Accounts/account_1413571863_0: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: No credentials found in the keyring (goa-error-quark, 4) If I don't setup any remote accounts during g-i-s, this error still occurs: Oct 17 11:51:16 localhost.localdomain gnome-session[1102]: ** (gnome-initial-setup:1256): WARNING **: Failed to change keyring password: GDBus.Error:org.gnome.keyring.Error.Denied: The password was invalid and I think possibly this one: Oct 17 11:51:19 localhost.localdomain gnome-keyring-daemon[1526]: failed to unlock login keyring on startup but if I then configure the OC account from Control Center *after* the initial login, it works and I don't get errors subsequently - I'm assuming in that case the keyring password gets successfully reset with the first addition of a credential to it, or something. This also occurs with 3.14.1, in a test live image I built (in fact at first I was figuring it was 3.14.1 regression, but further testing shows it also happens in 3.14.0 and we just hadn't noticed till now.)
Created attachment 288785 [details] full journalctl output from the first boot (ran g-i-s, created user account, configured OC acount, saw the bug)
so here's the funny thing - I'm testing it again for earlier builds to see if I can see when this broke, and one thing I note is that actually, steps 3 and 4 happen the other way around. You configure online accounts before you create a user account. Is this relevant to the problem, maybe? Where's it putting the credentials for the online account before a user account is created? The bug does occur with Fedora 21 Alpha. Same log output. Will check F20 Final next. F21 Alpha had g-i-s 3.13.5-2.fc21 and gnome-keyring 3.12.2-3.fc21.
F20's g-i-s did not offer Online Accounts configuration. After an F20 Final install, boot, and g-i-s user creation, there are no keyring errors in the journal.
(In reply to comment #3) > F20's g-i-s did not offer Online Accounts configuration. You bet your sweet kazoo it does; I used it earlier today. Easy to test from an existing F20 install by creating a new user and logging in to the new account. I'm also offered Online Accounts configuration when I do a new F20 install, but I have anaconda create the initial user and that might be the difference....
yes, that's a different mode. I think we turned it off for the user-creation mode of F20's g-i-s for some reason, but I forget the details. As that's a different path from this bug, I didn't mention / test it.
Created attachment 289056 [details] [review] password: Fix changing the login keyring password We are trying to update the login keyring password using uninitialized memory as the old password from gis_driver_get_user_permissions() but there's no password since we only set the first one below. In fact, the gis-keyring API doesn't even need the "old" password to be a parameter, we can just hardcode one which makes everything simpler and works as fine for our purpose.
Review of attachment 289056 [details] [review]: Looks like a simplification. +1
Attachment 289056 [details] pushed as 46910e9 - password: Fix changing the login keyring password