Bug 1222052 - gnome-keyring is inaccessible for password-less users
Summary: gnome-keyring is inaccessible for password-less users
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-initial-setup
Version: 22
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rui Matos
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F22FinalFreezeException
TreeView+ depends on / blocked
Reported: 2015-05-15 15:13 UTC by Kamil Páral
Modified: 2015-05-21 18:44 UTC (History)
10 users (show)

Fixed In Version: gnome-initial-setup-3.16.3-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-05-21 18:44:16 UTC
Type: Bug

Attachments (Terms of Use)
password dialog after trying to unlock the keyring with a passwordless user (16.34 KB, image/png)
2015-05-15 15:13 UTC, Kamil Páral
no flags Details
create new keyring dialog (20.00 KB, image/png)
2015-05-18 15:38 UTC, Kamil Páral
no flags Details
create new unprotected keyring dialog (19.57 KB, image/png)
2015-05-18 15:38 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2015-05-15 15:13:36 UTC
Created attachment 1025930 [details]
password dialog after trying to unlock the keyring with a passwordless user

Description of problem:
If I create password-less user (either during anaconda installation, or manually in terminal), that user can't access gnome keyring. The keyring is locked, and every attempt to unlock it (or to write to it, which implies unlocking) shows a dialog:

Enter password to unlock your login keyring
The login keyring did not get unlocked when you logged into your computer.
[Cancel]  [Unlock]

This is very confusing for the user, because the user was created password-less, it never had a password, and so there is nothing to input here.

Providing any value or no value at all does not unlock the keyring, cancel button cancels the whole operation.

In the end, password-less users can't store or read anything into/from the keyring, and every applications that tries to do so (even on the background, I suppose) makes the aforementioned dialog pop up.

Easily testable with Online Accounts, Empathy, Evolution, ABRT (try to set up bugzilla credentials). Anything that uses gnome-keyring is broken and can't be used (well, you can't save the password, so you would have to repeat it for every launch. not applicable for online-accounts, of course).

PLEASE NOTE: For some reason, if you don't create any user in anaconda, and use gnome-initial-setup on first boot to do that, you can create a passwordless user which *works* - his gnome-keyring password is empty, and keyring can be unlocked ok. I have no idea why that is.

Version-Release number of selected component (if applicable):
F22 TC4 Workstation Live x86_64

How reproducible:

Steps to Reproduce:
1. create a passwordless user. either create it in anaconda (there's a checkbox), or use `useradd user; passwd -d user`, or use gnome-control-center to create a user and then run `passwd -d user`
2. reboot, log in as that user
3. try to use any of those apps to save a password, you'll see that dialog and it won't work
4. run seahorse and see your login keyring locked, try to unlock it, same dialog

Actual results:
passwordless users have a very degraded experience, can't save passwords in any app supporting gnome-keyring

Expected results:
passwordless users have an empty password in gnome-keyring, things just work out of the box

Additional info:

Comment 1 Kamil Páral 2015-05-15 15:15:56 UTC
Proposing as a blocker:
"Saving passwords to and retrieving passwords from the default keyring must work for all release-blocking desktops. "

Please note that this is violated only for passwordless users, and just those created by anaconda or manually. The first system user, which can be created by gnome-initial-setup (as passwordless) is not affected.

Comment 2 Kamil Páral 2015-05-15 15:23:45 UTC
It turns out that the default keyring password is "gis", and g-i-s makes sure it gets updated during user creation. But if you create the user outside of g-i-s (or gnome-control-center), i.e. in anaconda or with useradd and passwd, nothing updates the default password.

For all that cases mentioned above, I can unlock the login keyring for passwordless users, if I use "gis" as a password.

Comment 3 Adam Williamson 2015-05-15 15:33:56 UTC
I'm probably -1 blocker +1 FE on this, nice catch though. Passwordless user case isn't the default or (I think) very common, and we can document the 'gis' password.

Comment 4 Kamil Páral 2015-05-15 16:53:47 UTC
Some more info:
This problem is actually present on F21 installer as well. There are these package versions:

However, later on, this seems to have been *fixed* in F21. On my updated F21 machine, if I create a user using useradd & passwd, no login keyring is created for him. After an app wants to access a keyring, I'm presented with a dialog asking me to create a 'default' keyring with my chosen password - or I can choose to create it passwordless. This is a great behavior - everything is clear and the user is given a choice whether to encrypt his passwords or not. The package versions on this F21 system are:

Maybe the minor change in gnome-initial-setup fixed it?

On F22, though, everything is back to be broken. I've also tried F22 Beta and F22 Alpha, all broken.

It depends on how fast GNOME team thinks they can fix this (i.e. introduce the same behavior as in updated F21). I'd rather slip a week than release it this way (that makes me a conditional +1). However, if this would be a complex change or people are generally -1 to this, we can document this and require this to be fixed for F23 at latest (hopefully sooner as an update).

Comment 5 Kamil Páral 2015-05-15 17:30:02 UTC
(In reply to Kamil Páral from comment #4)
> However, later on, this seems to have been *fixed* in F21. 

I take this back, I can't repeat it on the same system (now it fails the same way as in all other cases). I have no explanation for it, unless there is some kind of race condition involved.

Comment 6 Stephen Gallagher 2015-05-18 15:34:44 UTC
I'm -1 blocker on this: password-less installations are rare and the recommended approach is "set a password, then turn on auto-login" anyway.

I'm actually -1 Freeze Exception in this case, since messing with the default password configuration and the keyring seems rather risky for this point in the development cycle. I'd prefer to document the limitation in Common Bugs and move on.

Comment 7 Kamil Páral 2015-05-18 15:38:30 UTC
Created attachment 1026755 [details]
create new keyring dialog

I have tested this patch:

There is no change in behavior for users having a password (that's correct). For password-less users, the behavior changed to the one described in comment 4 - by default, there is no login keyring at all. After first attempt to access it (e.g. saving login credentials in abrt), the user is asked to create a 'default' keyring with desired password (it is possible to create it unprotected as well).

I'm attaching screenshots for you to have an idea how it looks like.

Comment 8 Kamil Páral 2015-05-18 15:38:53 UTC
Created attachment 1026756 [details]
create new unprotected keyring dialog

Comment 9 Fedora Update System 2015-05-18 16:57:16 UTC
gnome-initial-setup-3.16.3-1.fc22 has been submitted as an update for Fedora 22.

Comment 10 Petr Schindler 2015-05-18 17:05:26 UTC
Discussed at today's blocker review meeting [1]. 

This bug was rejected as blocker but accepted as freeze exception: This bug could easily cause confusion for users who don't set up a password for their accounts, but is not common enough to warrant 

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-18

Comment 11 Kamil Páral 2015-05-20 06:26:46 UTC
This hasn't been included in RC1 by accident. If there's no RC2, we'll need to document this in common bugs.

Comment 12 Kamil Páral 2015-05-20 20:18:58 UTC
This seems to be fixed in RC2. I created a passwordless user in anaconda and after installation it didn't have any keyring pre-defined and I was asked to create one on my first attempt to use it.

Comment 13 Fedora Update System 2015-05-21 18:44:16 UTC
gnome-initial-setup-3.16.3-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

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