GNOME Bugzilla – Bug 758592
Fix regressions to new user mode
Last modified: 2016-02-16 13:42:32 UTC
The 'new user' mode in g-i-s is the mode in which gnome-initial-setup runs as the gnome-initial-setup user, in a special gdm session which is unlike a normal user session. In this mode, gdm does not authenticate using the 'gdm-password' service but instead the gnome-initial-setup user runs in a session setup via the 'gdm-launch-environment' service, this all boils down to PAM, and the gnome-keyring which is not intitialized in the normal way via /etc/pam.d/gdm-password. This is why g-i-s originally needed to create the keyring manually by running gnome-keyring-daemon --unlock, which will simply bail out if given a null or empty password in the stdin. Further, in the g-i-s password page for the initial 'new user' that "gis" password needs to be updated with the password which the user selected so that the login keyring which is "handed off" to the new user bears a matching authentication token based on the same password. The branch 'new-user-mode-fixes' branch I've just pushed fixes these issues by reverting a couple of patches which introduced the regression causing the keyring to not be created or handed off, and additionally adds a patch on top of these to only do the keyring-foo for the 'new user' mode. There is no need to do the manual keyring-foo when not in 'new user' mode as the user would be logged in already via the gdm-password service where we rely on PAM configuration to properly initialize the keyring. This should also not be an issue for passwordless users, as those are not allowed in the 'new user' mode when creating the systems first user.
Indeed, there must have been a thinko in our attempt to create an unencrypted keyring. This is the code that is run for the --unlock option: https://git.gnome.org/browse/gnome-keyring/tree/daemon/login/gkd-login.c#n270 It clearly rejects an empty password.
so commit 69714499c2ac26 reintroduces a dbus call with the interface: org.gnome.keyring.InternalUnsupportedGuiltRiddenInterface Maybe a better approach would be to allow --unlock to work with empty passwords? Alternatively, if we're okay with the guilt of relying on private interfaces, perhaps, we should just do the equivalent of: echo > ~/.local/share/keyrings/login.keyring << EOF [keyring] display-name=login lock-on-idle=false lock-after=false EOF and bypass gnome-keyring in creating the keyring entirely? I do also wonder, out of curiosity, if things work with just commit 69714499c2ac26 added back, without changing the password to a non-empty string (i.e. was the --unlock actually unneeded). Stef, backstory is gnome-initial-setup creates the keyring before the user is created / has set a password. things like wireless AP secrets might get stuffed in it during initial setup. once the user is created in initial setup we want the new account to have a keyring initialized with those secrets, but encrypted using the new account's password. What's the best way to achieve that?
regardless what we do for keyring creation, the top patch (only doing keyring creation for first boot, not first login) makes sense.
Created attachment 321022 [details] [review] only create keyring manually for new user mode gnome-initial-setup has code to create a login keyring. This is used the first boot after an install as a staging area for account passwords set up during gnome-initial-setup. If gnome-initial-setup is run at login time instead of at boot time (if it gets run on an existing user, instead of getting run to create a new user), then there is no need to create the login keyring. It will have already been created when the user first logged in. This commit avoids touching the keyring in that case.
Review of attachment 321022 [details] [review]: this is the patch from the branch. I changed up the description a little and will push
Comment on attachment 321022 [details] [review] only create keyring manually for new user mode Attachment 321022 [details] pushed as 59dfa4f - only create keyring manually for new user mode
mclasen> to make it quick: should --unlock accept an empty password and create an unencrypted keyring ? stefw> i guess it could, but i suspect it doesn't mclasen> indeed, it doesn't which causes g-i-s to fail at creating a keyring the alternatives for fixing it are a) create the 3-line keyfile ourselves or b) get unlock to accept "" as a password stefw> mclasen, b) would be welcome i think. not against such a patch
I've filed bug 762095 on the gnome-keyring side
Should be fixed