Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 518566 - gnome-base/gnome-keyring-3.12 - different gnome-keyring-daemon processes uses the same path for sockets
Summary: gnome-base/gnome-keyring-3.12 - different gnome-keyring-daemon processes uses...
Status: RESOLVED DUPLICATE of bug 516848
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GNOME (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-30 09:00 UTC by Alexander Tsoy
Modified: 2014-10-28 18:48 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Tsoy 2014-07-30 09:00:21 UTC
Each gnome-keyring-daemon process uses the same path for keyring sockets and recreates them at startup. So after login via ssh newly spawned gnome-keyring-daemon processes breaks further usage of gnome-keyring (eg. ssh and gpg keyrings) from graphical session.

$ ls -1i /run/user/1000/keyring/
878887 control
878891 gpg
878894 pkcs11
878889 ssh

after the next login via ssh on this machine:

puleglot@work ~ $ ls -1i /run/user/1000/keyring/
897002 control
897006 gpg
897012 pkcs11
897004 ssh


How this breakage looks from the gnome session:

$ ssh 192.168.2.67 
Agent admitted failure to sign using the key.
Password:

and following lines appears in the journal:

gnome-keyring-daemon[14890]: couldn't create system prompt: Error spawning command line 'dbus-launch --autolaunch=c445389dad1966ced583b8bb0000000d --binary-syntax --close-stderr': Child process exited with code 1


Related upstream change:

[1] https://git.gnome.org/browse/gnome-keyring/commit/?id=275a696131e41ea4be3d3ddf6690b8bcd0fe0105
Comment 1 Alexander Tsoy 2014-07-30 09:08:31 UTC
Do we really need pam_gnome_keyring in /etc/pam.d/system-login? I think it should go into individual pam configs for login managers.

$ grep gnome_keyring /etc/pam.d/system-login
auth		optional	pam_gnome_keyring.so
password	optional	pam_gnome_keyring.so
session		optional	pam_gnome_keyring.so auto_start
Comment 2 Alexander Tsoy 2014-07-30 09:09:15 UTC
(In reply to Alexander Tsoy from comment #1)
> login managers.

display managers
Comment 3 Alexander Tsoy 2014-07-31 09:31:49 UTC
(In reply to Alexander Tsoy from comment #1)
> $ grep gnome_keyring /etc/pam.d/system-login
> auth		optional	pam_gnome_keyring.so
> password	optional	pam_gnome_keyring.so
> session		optional	pam_gnome_keyring.so auto_start

I just realized that it is controlled by the gnome-keyring use flag in pambase ebuild. Rebuilding pambase with USE=-gnome-keyring solved this problem for me.

(In reply to Alexander Tsoy from comment #0)
> Related upstream change:
> 
> [1]
> https://git.gnome.org/browse/gnome-keyring/commit/
> ?id=275a696131e41ea4be3d3ddf6690b8bcd0fe0105

So upstream does not support multiple gnome-keyring-daemon instances per user and it's really make no sense to run gnome-keyring-daemon in non-graphical sessions. I think the following blocker should be added to gnome-base/gnome-keyring ebuilds: "!sys-auth/pambase[gnome-keyring]".
Comment 4 Alexander Tsoy 2014-10-28 18:48:21 UTC

*** This bug has been marked as a duplicate of bug 516848 ***