GNOME Bugzilla – Bug 662528
Need signal matching Setenv dbus method so apps in initialization phase can update their env too
Last modified: 2014-10-19 19:08:53 UTC
Last few days i observed that i have to enter the password of my ssh key manually each time i connect to a remote machine. "Normally" this is handled by, i believe, gnome-keyring. Since 3.2.1 this feature is (for me) not working anymore Running ubuntu 11.10 gnome-keyring: 3.2.1 Not sure if thats the correct package to file the bug against.
Could you provide the output of the following commands? $ ps -xa | grep gnome-keyring $ set | grep SSH
here you go dan@Greyskull:~$ ps -xa | grep gnome-keyring Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html 1814 ? SLl 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login 1939 ? S 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets dan@Greyskull:~$ set | grep SSH SSH_AGENT_PID=1863 SSH_AUTH_SOCK=/tmp/ssh-ouRXjGix1824/agent.1824
It seems that gnome-keyring-daemon is not being initialized properly. On startup. Could you look at /var/log/auth.log and see if there are messages from gnome-keyring-daemon? Additionally could you make sure that the "SSH Key Agent" is checked and enabled in the dialog that appears when you run "gnome-session-properties".
In gnome-session-properties there is no ssh key agent entry, just one for the gnome-keyring, but it was never needed before. Next time the problem occurs ill check auth.log and report back, its not reproduceable for me on every boot. 50:50 chance atm.
That's strange (in addition to being started from pam), gnome-keyring is started by the session, and if it's not listed in gnome-session-properties then something seems broken. It should be checked there by default.
gnome-keyring is listed in the session-properties, ssh agent is not tho. "Gnome Secret Storage Service" is the entry (/usr/bin/gnome-keyring-daemon --start --components=secrets )
What does this give you: $ ls /etc/xdg/autostart/gnome-keyring-*
dan@Greyskull:~$ ls /etc/xdg/autostart/gnome-keyring-* /etc/xdg/autostart/gnome-keyring-gpg.desktop /etc/xdg/autostart/gnome-keyring-pkcs11.desktop /etc/xdg/autostart/gnome-keyring-secrets.desktop /etc/xdg/autostart/gnome-keyring-ssh.desktop
That's really wierd. I don't understand why those listed in the startup applications? At this point I'm looking suspiciously at Ubuntu, but let's see if we can get to the bottom of this. Are you on gimp.net irc? Can you join me at #keyring?
Took a while to resurface but here we go: dan@Greyskull:~$ ps aux|grep keyring dan 1852 0.0 0.1 168028 5724 ? SLl 21:54 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login dan 1989 0.0 0.0 58256 1972 ? S 21:54 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets dan@Greyskull:~$ ps aux|grep ssh-agent dan 1919 0.0 0.0 12264 272 ? Ss 21:54 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/gnome-session --session=gnome-classic dan@Greyskull:~$ echo $GNOME_KEYRING_PID 1852 dan@Greyskull:~$ ps aux|grep 1852 dan 1852 0.0 0.1 168028 5724 ? SLl 21:54 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login dan 3163 0.0 0.0 16160 916 pts/4 D+ 22:16 0:00 grep --color=auto 1852 dan@Greyskull:~$ echo $SSH_AUTH_SOCK /tmp/ssh-FGvruYIC1867/agent.1867 (that one is different) d-feet -> secrets says -> keyring-daemon --daemonize --login hope that helps
Sorry took a while to get to this. From the processes and SSH_AUTH_SOCK it appears that gnome-keyring-daemon isn't getting the chance to set its environment variables correctly. Here's how it should work in your situation: 1. gnome-keyring-daemon initially started (but not initialized) by pam. 2. later during the startup of gnome-session, the autostart files are run and gnome-keyring-daemon initializes itself using the current environment. 3. during initialization gnome-keyring-daemon sets session environment variables in the gnome-session-daemon using the SetEnv() dbus interface. So two things could be failing (intermittently). Either in step 2, the autostart files aren't being run, or in step 3 the session isn't accepting the environment variables. If the failure is in step 3 then there should be log output in your /var/log/auth.log, could you include relevant lines from there next time this happens? Other than that I'm not really able to troubleshoot this further without actually hands on. Have other Ubuntu users reported this to Ubuntu's bug tracker?
This is a terrible show-stopping bug for ssh-agent users in gnome3, but I don't think it is related to gnome-keyring. The best explanation I have found is in the Ubuntu bug https://bugs.launchpad.net/debian/+source/gnome-session/+bug/839444 Apparently there are two separate ssh-agent invocations when you log in, so you give one key for things you do from the shell explicitly, but if you do a custom keybinding those keys don't apply and it asks you for a passphrase every time. Apparently the custom keybinding is started before the ssh-agent for the rest of the session, so there are separate SSH_AUTH_SOCK variables.
Aha, that makes sense. Reassigning to gnome-session.
Good catch.
Created attachment 205040 [details] [review] manager: add the EnvironmentSet signal gnome-session patch
Created attachment 205041 [details] [review] main: rename on_session_over to on_session_proxy_signal
Created attachment 205042 [details] [review] main: update environment on EnvironmentSet
Created attachment 205043 [details] [review] main: move the env vars we set in a static array
Created attachment 205044 [details] [review] main: don't update environment for the variables we set ourselves
[ last four patches against gnome-settings-daemon ] After talking with Vincent and Stefan on IRC it looks like this should be the approach. It looks like it's not enough though; gnome-settings-daemon will not receive any signal in response the calls made to Setenv(), probably because those are made just between the time gnome-settings-daemon is spawned and the time it connects to the gnome-session DBus proxy signals (I verified that the Setenv() calls are received correctly on the gnome-session side). I don't have enough knowledge of the interactions here, so I will wait for someone else to chip in, but my first thought would involve adding a Getenv() call, that would return all the variables set with Setenv() (which in turn would have to be cached by gnome-session).
Setenv was not a great idea to begin with...this is just making matters worse, imo. Calling setenv is not threadsafe. At least for the LC_ variables that g-s-d is setting from gsettings, we should just make gnome-session read those directly out of gsettings.
(In reply to comment #21) > Setenv was not a great idea to begin with...this is just making matters worse, > imo. Calling setenv is not threadsafe. > > At least for the LC_ variables that g-s-d is setting from gsettings, we should > just make gnome-session read those directly out of gsettings. I agree on both points. As far as I can understand from gnome-session's README, the real problem is the current session startup design kind of assumes things started in the initialization phase will not need the environment variables as set with SetEnv() (it's inherently racy) which is bad if you have to spawn processes for e.g. keybindings. This was not a problem in the past because keybindings were handled entirely by the window manager, which is started only in the next phase. I think an approach to solve this problem could be to make gnome-session's environment handling stateful; e.g. gnome-session could export a org.gnome.SessionManager.GetEnv(), and gnome-settings-daemon could query for the current environment and regenerate envp before spawning its children, or something. One problem with this approach is gnome-settings-daemon itself has UI to display, so it would need to set the environment for itself as well. Another longer-term fix would involve moving all the process spawning to a separate component (systemd anyone?) and make that ensure the environment is always up-to-date. Probably though, a better shorter term fix is to - move gnome-settings-daemon locale handling to gnome-session as suggested by Matthias - have gnome-settings-daemon read the keyring environment directly out of gnome-keyring after it appeared on the bus
Other unintended breakage caused by this (well, a combination of this and broken assumptions elsewhere): I use a keybinding to spawn my terminals and hack on projects. gnome-shell sets some environment variables which cause gjs to display printf messages to stderr by default [1]. Since now terminals do not inherit those env vars anymore, calling log() in gjs from a terminal spawned with a keybinding don't yield any output. [1] http://git.gnome.org/browse/gnome-shell/tree/src/main.c#n311
arguably gjs should do that by default, but I don't think gnome-shell's intention was to fix gjs output for other programs. So, in some ways, this breakage is actually more technically right.
(In reply to comment #24) > arguably gjs should do that by default, but I don't think gnome-shell's > intention was to fix gjs output for other programs. So, in some ways, this > breakage is actually more technically right. I completely agree (I fixed gnome-documents to set the same gjs variables like the shell does)...this was more a point for myself and others that might stump in the same issue while this is fixed.
After some pause the bug occured again. Any more information i can provide?
*** Bug 661642 has been marked as a duplicate of this bug. ***
I'd personally go with: - make gnome-session read (and update) the LC_* envvars itself from GSettings (and remove that code from gnome-settings-daemon) - have gnome-settings-daemon read the interesting envvars directly from gnome-keyring (ssh, GPG, others?) Opinions? In the meanwhile, restarting gnome-settings-daemon by hand would make it pick up the new environment.
*** Bug 582436 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > In the meanwhile, restarting gnome-settings-daemon by hand would make it pick > up the new environment. Yeah this would makes sense to me, and is basically the same conclusion I got to in comment 22.
I agree too. Who writes the patch(es) ?
gnome-keyring-daemon exposes its environment variables via DBus. [stef@stef-desktop ~]$ dbus-send --session --dest=org.gnome.keyring --print-reply /org/gnome/keyring/daemon org.gnome.keyring.Daemon.GetEnvironment method return sender=:1.33 -> dest=:1.532 reply_serial=2 array [ dict entry( string "GNOME_KEYRING_CONTROL" string "/data/.cache/keyring-z7dTVa" ) dict entry( string "GPG_AGENT_INFO" string "/data/.cache/keyring-z7dTVa/gpg:0:1" ) dict entry( string "SSH_AUTH_SOCK" string "/data/.cache/keyring-z7dTVa/ssh" ) ] These are only valid after the gnome-keyring-daemon autostart stuff has run. The gnome-keyring autostart files complete the initialization of the gnome-keyring-daemon that was started by PAM. There are multiple autostart files so people can disable the SSH, GPG and PKCS#11 agents independently. Won't it difficult to figure out when gnome-keyring-daemon components have been initialized these environment variables are available?
Created attachment 210934 [details] [review] media-keys: Get the environment from gnome-keyring When launching custom applications.
(In reply to comment #33) > Created an attachment (id=210934) [details] [review] > media-keys: Get the environment from gnome-keyring > > When launching custom applications. That works for me for the purpose of launching custom applications. If there are any other program launched by g-s-d which need this done as well, it should be a quick fix. Does this fix the whole bug, or do we need a broader solution?
Although I'm only a user, the fix in #33 seems a bit too specific, even if it works. For a long time I was wondering, wouldn't it be possible for gnome-session to allow calling SetEnv at any time, and send an "environment changed" signal for gnome-settings-daemon to pick up? (In Windows, programs can broadcast a WM_SETTINGCHANGE message, causing the shell (Explorer) to refresh its own environment from the updated "master copy" kept in Registry.)
(In reply to comment #35) > Although I'm only a user, the fix in #33 seems a bit too specific, even if it > works. What's the use case which would break? I want to fix "terminals launched via shortcuts don't know about the gnome ssh agent", not "passing envvars to programs sucks" > For a long time I was wondering, wouldn't it be possible for gnome-session to > allow calling SetEnv at any time, and send an "environment changed" signal for > gnome-settings-daemon to pick up? gnome-session's environment only changes during the startup phase. > (In Windows, programs can broadcast a WM_SETTINGCHANGE message, causing the > shell (Explorer) to refresh its own environment from the updated "master copy" > kept in Registry.) We have GSettings for non-legacy applications. Makes no sense to me to try and fix environment passing sucking on Unix systems.
Review of attachment 210934 [details] [review]: I haven't tested it, but this seems like a decent quick fix. We really want long term is to send patches to ssh and gpg to look for ssh and gpg agents in XDG_RUNTIME_DIR. Or some better solution than passing around environment variables...
Review of attachment 210934 [details] [review]: I also think this would be a good fix for 3.4; just a minor comment on the code. ::: plugins/media-keys/gsd-media-keys-manager.c @@ +260,3 @@ + envp = g_get_environ (); + + NULL, I think you're supposed to free the iterator with g_variant_iter_free()
commit a9388f70abc975da31c90867d9ab9bd7253b1d30 Author: Bastien Nocera <hadess@hadess.net> Date: Fri Mar 30 11:36:58 2012 +0200 media-keys: Get the environment from gnome-keyring When launching custom applications. https://bugzilla.gnome.org/show_bug.cgi?id=662528
Let's consider this done (committed to master, so GNOME 3.4 too). File new bugs if you have particular use cases which weren't covered (unbreaking the unholy mess that is envvar using in Unix isn't a use case).
Thanks all, I really appreciate the fix!
*** Bug 674053 has been marked as a duplicate of this bug. ***
After manually adding /usr/bin/gnome-keyring --start --components=secrets to gnome-session-properties the old behaviour of saving ssh-keywords in a session is restored.
Not sure if 1. my setup is wrong 2. i should reopen this one 3. fill in a new one..., but $ ssh-add -L Could not open a connection to your authentication agent. $ ps -aux | grep keyring buddho 1661 0.0 0.2 536484 8004 ? Sl 15:57 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login $ dbus-send --session --dest=org.gnome.keyring --print-reply /org/gnome/keyring/daemon org.gnome.keyring.Daemon.GetEnvironment method return sender=:1.29 -> dest=:1.123 reply_serial=2 array [ dict entry( string "GPG_AGENT_INFO" string "/run/user/1000/keyring/gpg:0:1" ) dict entry( string "SSH_AUTH_SOCK" string "/run/user/1000/keyring/ssh" ) ] in case this helps: $ echo $SSH_AUTH_SOCK (i mean this is empty)
forgot the important part $ gnome-keyring-daemon -V gnome-keyring-daemon: 3.14.0 testing: enabled
(In reply to comment #45) > forgot the important part > > $ gnome-keyring-daemon -V > gnome-keyring-daemon: 3.14.0 > testing: enabled sorry this is https://bugzilla.gnome.org/show_bug.cgi?id=738205