the ssh agent is correctly used when using a normal password login and libpam-keyring integration to gdm, otherwise the GNOME_KEYRING_* environment variables are not set and the agent is not working correctly. 
The processus is "/usr/bin/gnome-keyring-daemon" is the non working case and "/usr/bin/gnome-keyring-daemon -d --login" in the working one.

Created attachment 101029 [details] [review]
Use all environment variables from gnome-keyring-daemon

Does this patch to gnome-session do the trick?

The patch fixes the issue

*** Bug 504172 has been marked as a duplicate of this bug. ***

Ok to commit the attached patch to gnome-session along with an appropriate ChangeLog? 

I'm not fond of the "blindly trust the output" way. How many environment variables are there? Maybe they could be outputted on another file descriptor to make it safer?

Also, I believe the new gnome-session has a dbus api to set environment variables. Or that it was planned.

(In reply to comment #6)
> Also, I believe the new gnome-session has a dbus api to set environment
> variables. Or that it was planned.

It does (org.gnome.SessionManager.SetEnv), but is that happening for 2.22?
(Although it would be easy enough to copy just that part over to the old
gnome-session if not...)

There's also going to be a problem with dbus-daemon-launched processes...
we may need to get dbus-daemon itself to have a setenv-ing interface (which
would also solve the no-$SESSION_MANAGER-in-dbus-launched-processes problem).

The daemon is designed to only output environment variables on stdout (before it forks). There are currently four environment variables:

GNOME_KEYRING_PID
GNOME_KEYRING_SOCKET
SSH_AUTH_SOCKET
SSH_AGENT_PID

In the future that may also include:

GPG_AGENT_INFO

Of note: gnome-session is only one way that the daemon can be started, at the discretion of the distro. 

I'll try and come up with a better and more discriminate solution by moving a most of the gnome-keyring related code in gnome-session into the gnome-keyring library.

Created attachment 105270 [details] [review]
Exchange environment variables with daemon properly

Attached is a patch which properly initializes the daemon. 
 * Accepts relevant environment variables from the daemon.
 * Sends environment variables (such as DBUS_SESSION_ADDRESS, XAUTHORITY) to the daemon.

The above functionality is in libgnome-keyring, this patch just calls the appropriate functions. 

This is necessary for gnome-keyring to work on systems where it is started by PAM before most of the rest of the session comes up. It also fixes problems with the SSH environment variables not propogating to the session.

Ok to commit? 

I'm marking this as a blocker, I hope that's okay. Without this patch:

 * gnome-keyring prompts just plain don't work on many configurations, 
   and this breaks applications that store passwords.
 * The gnome-keyring SSH agent doesn't work (seahorse removed its agent).
 * Multiple copies of gnome-keyring are started erroneously.

Thanks, I've committed your patch with slight changes to improve readability.

Stef: with the patch, my gnome-session is now blocked in gnome_keyring_daemon_prepare_environment_sync()->run_sync_operation()->read_all()->read()

Killing the keyring daemon unblocks this...

The daemon disconnects (has always been this way) when it receives
something it doesn't recognize. Do unix sockets really hang when the
other end closes without first sending data through the socket?

In any case I've committed a patch to gnome-keyring which calls
shutdown() before close(), and should hopefully alleviate the problem.

The patch breaks my setup: I'm starting gnome-session with the env vars of a launched ssh-agent[1]; when gnome-session is started, SSH_AUTH_SOCK and SSH_AGENT_PID are in the env, but gnome-keyring-manager provides another 
SSH_AUTH_SOCK overriding the one I'd like to use.

This is goofy:
1) gnome-keyring decides to hide an already running agent; I think this is an important bug in gnome-keyring

2) I end up with SSH_AGENT_PID set to my ssh-agent process (which I can't use) and keychain continues injecting keys into this process as it still has a copy of the env vars in ~/.keychain; SSH_AUTH_SOCK points to gnome-keyring though so my SSH_* env vars are inconsistent; at the very least gnome-keyring could also request to unsetenv this var or setenv to itself.

I think this should be fixed in gnome-keyring, but please revert this change until it's the case.

[1] launched by keychain in ~/.gnomerc; .gnomerc is handled by Debian's /etc/X11/Xsession

A workaround is to set /apps/gnome-keyring/daemon-components/ssh to false.

Perhaps gnome-keyring-daemon should gain a --force flag to start requested/configured components even if they seem to be already provided, and don't start them if not given; Stef, I think you're working on g-k: what do you think?

Loïc: we can't simply revert this patch, else gnome-keyring support will be broken. gnome-keyring just needs to be fixed.

Filed bug #519486 for the first issue, and #519487 for the second one.