After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 625053 - pam_gnome_keyring only uses keyrings with 'login' name
pam_gnome_keyring only uses keyrings with 'login' name
Status: RESOLVED WONTFIX
Product: gnome-keyring
Classification: Core
Component: general
2.30.x
Other Linux
: Normal minor
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-07-22 18:03 UTC by Iuri Diniz
Modified: 2012-03-19 14:08 UTC
See Also:
GNOME target: ---
GNOME version: 2.29/2.30



Description Iuri Diniz 2010-07-22 18:03:48 UTC
Hello folks, 

pam_gnome_keyring.so only unlock the keyring using the password provided
if the keyring has 'login' name

/var/log/auth.log:
Jul 21 19:13:14 folha gnome-keyring-daemon[1077]: Failed to unlock login on startup

How to reproduce:
1) create a new keyring using seahorse, set it as default, move some passwords 
to it (wifi password per example); 
2) optionally remove the old keyring;

[ or you can rename old keyring via 'mv $HOME/.gnome2/keyrings/login.keyring $HOME/.gnome2/keyrings/default.keyring' and alter $HOME/.gnome2/keyrings/default]

Possible solutions:
1) pam-gnome-keyring may honour $HOME/.gnome2/keyrings/default; or
2) pam-gnome-keyring must unlock each keyrings with the provided password

OS: Ubuntu Lucid 10.04 with the latest updates,
Version: Version: 2.92.92.is.2.30.3-0ubuntu1
Comment 1 Iuri Diniz 2010-07-22 18:13:24 UTC
If this feature is not done in trunk I like to do it if someone could help me
Comment 2 Stef Walter 2012-03-15 09:36:04 UTC
This could be done as an argument to the pam module. So that in the pam configuration you would specify a different keyring to unlock. By default (when that config argument was not present) it would default to using the 'login' keyring.

Are you still interested in working on this?
Comment 3 Iuri Diniz 2012-03-16 12:10:24 UTC
Well, I think that is very simple to do, So I will try to work on it next weekend and submit a patch to this bug
Comment 4 Stef Walter 2012-03-16 21:08:39 UTC
That would be great, thanks.
Comment 5 Iuri Diniz 2012-03-18 14:09:21 UTC
Seems more complicated :-( and I need help. 

pam_gnome_keyring (pam/gkr-pam-client.c:keyring_daemon_op) sends a GKD_CONTROL_OP_UNLOCK( to daemon in order to unlock. 

I think that daemon/control/gkd-control-server.c:control_unlock_login handles this op. How can I pass which keyring it will unlock (if possible).
Comment 6 Stef Walter 2012-03-19 11:17:01 UTC
Yeah, you're right it is more complex. In addition there's a lot of logic that treats the 'login' keyring as special. For example passwords you request to "Automatically unlock" are stored there. What was the use case for not wanting to use the login keyring?
Comment 7 Iuri Diniz 2012-03-19 13:05:52 UTC
I've found that if there is no 'login' keyring, it creates a 'login' keyring and it shows a dialog box in order to unlock any other keyrings and store their password on 'login' keyring to auto unlock it next login.

So, it will use other keyrings in cascade and I think there isn't any useful case for not using the 'login' keyring.

closing this ticket
Comment 8 Stef Walter 2012-03-19 14:08:51 UTC
Thanks.