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 578708 - Regression: SFTP module does not use SSH agent from gnome-keyring
Regression: SFTP module does not use SSH agent from gnome-keyring
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: sftp backend
git master
Other Linux
: Normal major
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks: 577614
 
 
Reported: 2009-04-11 16:03 UTC by Stef Walter
Modified: 2009-12-15 21:12 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Patch to set SSH_AUTH_SOCK correctly (2.89 KB, patch)
2009-04-11 16:04 UTC, Stef Walter
none Details | Review

Description Stef Walter 2009-04-11 16:03:00 UTC
In many cases in GNOME 2.26, gvfsd is started (by DBus activation) before gnome-keyring-daemon autostart is run, the correct environment variable "SSH_AUTH_SOCK" is missing when running gvfs-sftp. This prevents ssh from accessing the correct gnome-keyring SSH agent as expected. 

Discussed on DDL: http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00050.html

Also discussed at companion gnome-keyring issue: bug #577614

I'll attach a patch which manually gets the SSH_AUTH_SOCK environment variable from gnome-keyring. This is not a beautiful way of doing things, but it does fix the regression.

A nicer way would be to prioritize the order in which gnome-session runs the stuff in the 'autostart' directory. I don't think this is currently possible.
Comment 1 Stef Walter 2009-04-11 16:04:34 UTC
Created attachment 132518 [details] [review]
Patch to set SSH_AUTH_SOCK correctly

It'd be awesome to get this in before 2.26.1 if at all possible. Once approved, I can do the commit work to make it happen.
Comment 2 Alexander Larsson 2009-04-13 17:49:16 UTC
There are some issues:

+  results = g_hash_table_new_full (g_str_hash, g_str_equal, g_free, g_free);

This seems unused and leaked.

setup_ssh_environment() does blocking i/o in try_mount which should be moved to do_mount().

Everything is a bit g_warning trigger happy.
Comment 3 Stef Walter 2009-04-13 19:21:54 UTC
I noticed you've fixed things up and committed. Thanks. Much appreciated.
Comment 4 Landry Breuil 2009-12-15 21:12:04 UTC
If possible, i'd like this bug report to be reopened (i don't seem to have the rights for that).
Point is, now gvfsd-sftp inconditionally takes SSH_AUTH_SOCK from gnome-keyring-daemon over DBUS, while there could be another ssh agent running, with SSH_AUTH_SOCK pointing to its auth sock. Users not running gnome could be misleaded in thinking they talk to their bare ssh-agent (launched by their xinitrc, or a system wide xinitrc) while in fact it spawns a g-k-r session process which 'overrides' their ssh-agent.

A possible fix is :

--- daemon/gvfsbackendsftp.c.orig       Mon Dec 14 21:48:12 2009                                                                           
+++ daemon/gvfsbackendsftp.c    Mon Dec 14 21:50:24 2009                                                                                   
@@ -1646,7 +1646,8 @@ real_do_mount (GVfsBackend *backend,                                                                                 
               GMountSource *mount_source,                                                                                                 
               gboolean is_automount)                                                                                                      
 {                                                                                                                                         
-  setup_ssh_environment ();                                                                                                               
+  if (g_getenv("SSH_AUTH_SOCK") == NULL)                                                                                                  
+    setup_ssh_environment ();                                                                                                             
                                                                                                                                           
   do_mount (backend, job, mount_spec, mount_source, is_automount);                                                                        
 }                                                                                                                                         

Another one could be (untested) calling g_setenv() in setup_ssh_environment() with FALSE as last argument, so that it doesn't override a possible existing value, but this option would still spawn an unneeded g-k-r process.