upstart job race prevents gnome-keyring from being ssh agent

Bug #1271591 reported by Marc Deslauriers
210
This bug affects 38 people
Affects Status Importance Assigned to Milestone
gnome-keyring (Ubuntu)
Fix Released
High
Dimitri John Ledkov
Trusty
Fix Released
High
Dimitri John Ledkov

Bug Description

I expect gnome-keyring to be the ssh authentication agent when I am logged in to a graphical session.

Because of what I suspect is a race in upstart jobs, I believe SSH_AUTH_SOCK is being overwritten after gnome-keyring starts.

Perhaps the gnome-session job needs to make sure the ssh-agent job is finished?

[testcase]
1) Perform desktop login
2)
[ "$GNOME_KEYRING_CONTROL/ssh" = "$SSH_AUTH_SOCK" ] && echo Good || Fail

Expected output: Good

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: gnome-session 3.9.90-0ubuntu5
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
Uname: Linux 3.13.0-5-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Jan 22 10:25:59 2014
InstallationDate: Installed on 2013-11-26 (56 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
PackageArchitecture: all
SourcePackage: gnome-session
UpgradeStatus: Upgraded to trusty on 2014-01-17 (4 days ago)

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

I was wondering, if that's just me or everyone. It appears that gnome-keyring does not ship user-session jobs & the default ssh-agent is used from openssh-client package, which does ship user-session job.

So gnome-keyring should provide user session jobs for all of it's agents & export the AGENT environment variables, similar to the ssh-agent job.

affects: gnome-session (Ubuntu) → gnome-keyring (Ubuntu)
Changed in gnome-keyring (Ubuntu):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

/etc/xdg/autostart/gnome-keyring-pkcs11.desktop
/etc/xdg/autostart/gnome-keyring-ssh.desktop
/etc/xdg/autostart/gnome-keyring-gpg.desktop
/etc/xdg/autostart/gnome-keyring-secrets.desktop

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

gnome-keyring updates SSH_AUTH_SOCK by calling gnome-session's Setenv DBus method.
gnome-session then calls DBus's UpdateActivationEnvironment so that dbus activated clients also get the env variable.

Perhaps adding the upstart job, but leaving the autostart desktop files in place is sufficient?

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

This may also be the cause of bug 1259564

Revision history for this message
Andre Tomt (andre-tomt) wrote :

I see what I think is this bug on 3 different computers running 13.10, 2 installed with 13.10, 1 upgraded from 12.10.

Often what ssh agent is tried depends on how I start the terminal - the agent environment is set differently if started from the dash, launcher or alt-ctrl-t. And sometimes they all work like they should.

Revision history for this message
Leon (leonbo) wrote :

I can confirm what Andre is saying: launching a terminal via the launcher or the dash (or synapse) results in Unity not using gnome-keyring. If I launch via ctrl-alt-t gnome-keyring is used.

Launch via the dash:
SSH_AGENT_PID=2253
SSH_AUTH_SOCK=/tmp/ssh-y0YsIQziIbZX/agent.2249

Launch via ctr-alt-t:
SSH_AGENT_PID=2253
SSH_AUTH_SOCK=/run/user/1000/keyring-0WLPB7/ssh

tags: added: ubuntu-desktop-trusty
Revision history for this message
Øyvind Stegard (oyvindstegard) wrote :

I have chosen to unlock my GPG key at login time. In processes launched by Unity, I sometimes get the GPG_AGENT_INFO environment variable set, but other times (in other login sessions) not. So likely some kind of race. From terminal launched with Ctrl+Alt+T, the variable always seems to be available. (Emacs, which I usually launch from Unity, needs this variable to connect to gpg agent.)

Fully updated 14.04 and clean installation.

Revision history for this message
Damien Cassou (cassou) wrote :

Is there any workaround so that all applications started from the dash can benefit from the agent?

Changed in gnome-keyring (Ubuntu Trusty):
assignee: nobody → Dimitri John Ledkov (xnox)
Changed in gnome-keyring (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
Changed in gnome-keyring (Ubuntu Trusty):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-keyring - 3.10.1-1ubuntu5

---------------
gnome-keyring (3.10.1-1ubuntu5) utopic; urgency=medium

  * debian/gnome-keyring.conf: upstart user-session job to re-export
    gnome-keyring agent's sockets into the desktop environment. (LP:
    #1271591)
 -- Dimitri John Ledkov <email address hidden> Mon, 28 Apr 2014 13:40:08 +0100

Changed in gnome-keyring (Ubuntu):
status: Triaged → Fix Released
Changed in gnome-keyring (Ubuntu Trusty):
status: In Progress → Triaged
Changed in gnome-keyring (Ubuntu):
status: Fix Released → In Progress
Revision history for this message
CSRedRat (csredrat) wrote :

When this fixed in 14.04 Trusty Tahr for 14.04.1 (24 July)?

Revision history for this message
Bruno Nova (brunonova) wrote :

Finally found this bug report!
I have the same issue. Sometimes it happens, sometimes it doesn't.

Is the fix going to be backported to Tusty soon? That would be great.

Revision history for this message
Bruno Nova (brunonova) wrote :

In the meantime, just grab this file from here http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/gnome-keyring/utopic/view/166/debian/gnome-keyring.conf
(it's the fix) and put it in /usr/share/upstart/sessions/, then restart the session and see if the problem is gone forever.

Still, I'm waiting for the fix to appear in the Trusty repositories (should be trivial to backport).

Revision history for this message
Bruno Nova (brunonova) wrote :
Revision history for this message
Vlad Orlov (monsta) wrote :

More than four months passed - and the fix for a bug with "Importance" set to "High" isn't in Trusty yet?

Disappointing.

Steve Langasek (vorlon)
Changed in gnome-keyring (Ubuntu Trusty):
assignee: Dimitri John Ledkov (xnox) → James Hunt (jamesodhunt)
Changed in gnome-keyring (Ubuntu):
assignee: Dimitri John Ledkov (xnox) → James Hunt (jamesodhunt)
Revision history for this message
atimonin (atimonin) wrote :

It seems a better way would be to fix /etc/X11/Xsession.d/90x11-common_ssh-agent
(to start ssh-agent before gnome-keyring-daemon or not start it at all)
According to man page use of "initctl set-env --global" is discouraged

Changed in gnome-keyring (Ubuntu):
assignee: James Hunt (jamesodhunt) → Dimitri John Ledkov (xnox)
status: In Progress → Fix Released
Changed in gnome-keyring (Ubuntu Trusty):
assignee: James Hunt (jamesodhunt) → Dimitri John Ledkov (xnox)
status: Triaged → In Progress
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

@marga
with this change, gnome-keyring desktop session upstart job will take over ssh-agent upstart job in Trusty 14.04 LTS, and thus override SSH_AUTH_SOCK with the gnome-keyring's one. To disable this:

- system-wide: echo manual | sudo tee -a /etc/xdg/upstart/gnome-keyring.override
- user-wide: echo manual | tee -a ~/.config/upstart/gnome-keyring.override

description: updated
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

[ubuntu/trusty-proposed] gnome-keyring 3.10.1-1ubuntu4.1 (Waiting for approval)

gnome-keyring (3.10.1-1ubuntu4.1) trusty; urgency=medium

  * debian/gnome-keyring.conf: upstart user-session job to re-export
    gnome-keyring agent's sockets into the desktop environment. (LP:
    #1271591)

Revision history for this message
Chris J Arges (arges) wrote : Please test proposed package

Hello Marc, or anyone else affected,

Accepted gnome-keyring into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gnome-keyring/3.10.1-1ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in gnome-keyring (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Bruno Nova (brunonova) wrote :

I upgraded gnome-keyring to 3.10.1-1ubuntu4.1 from trusty-proposed in a virtual machine.

Before upgrading and rebooting, this bug was occurring.
After rebooting, the bug was gone. I rebooted about 5 times and tested ssh keys using gnome-terminal (started both from the Dash and from Ctrl+Alt+T) and it worked every time.

So, for me it's fixed!

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-keyring - 3.10.1-1ubuntu4.1

---------------
gnome-keyring (3.10.1-1ubuntu4.1) trusty; urgency=medium

  * debian/gnome-keyring.conf: upstart user-session job to re-export
    gnome-keyring agent's sockets into the desktop environment. (LP:
    #1271591)
 -- Dimitri John Ledkov <email address hidden> Mon, 13 Oct 2014 10:35:26 +0100

Changed in gnome-keyring (Ubuntu Trusty):
status: Fix Committed → Fix Released
Revision history for this message
Chris J Arges (arges) wrote : Update Released

The verification of the Stable Release Update for gnome-keyring has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
agnul (sucrabu) wrote :

Running gnome-terminal with the Alt-F2 shortcut the SSH_AUTH_SOCKET env variable is not set. Used to work until a couple of days ago, could this be related?

Revision history for this message
Vincent Cautaerts (vincent-cautaerts) wrote :

I have a problem similar to the one of 'agnul' since yesterday's update in ubuntu 14.04 (this update included gnome-keyring 3.10.1-1ubuntu4.1)

When I start a gnome-terminal with alt+F2, the environment is OK (SSH_AUTH_SOCK set)

When I start a terminal using a keyboard shortcut, the env is OK too.

When I start a terminal from the launch menu, the env is OK too.

But when I start it from a ".desktop" file, I don't get the SSH_AUTH_SOCK variable. It was working OK until yesterday's update.

Revision history for this message
Vincent Cautaerts (vincent-cautaerts) wrote :

Additionnal note to my last comment:

After downgrading to "gnome-keyring 3.10.1-1ubuntu4" (from "gnome-keyring 3.10.1-1ubuntu4.1"), loging out/in, it started working again: a terminal started form a '.desktop' file has the proper SSH_AUTH_SOCK variable.

Revision history for this message
Vlad Orlov (monsta) wrote :

Looks like the things got worse...

Though for us at Linux Mint things haven't really changed. Running mate-terminal via mintMenu still sets SSH_AUTH_SOCK to the wrong value (in /tmp dir).

Revision history for this message
Forest (foresto) wrote :

Based on the behavior I've observed, I think it's possible that there are two bugs in play here, and fixing one has revealed the other one.

I'm running Xubuntu 14.04.

Before this update, starting my terminal from the applications menu yielded a shell with SSH_AUTH_SOCK correctly pointing at gnome-keyring, while starting my terminal from a folder in Thunar file manager yielded a shell with SSH_AUTH_SOCK incorrectly pointing at an ssh-agent instance. The latter didn't work because I only have my ssh key loaded into gnome-keyring.

After the update, starting my terminal from the applications menu yields a shell with SSH_AUTH_SOCK correctly pointing at gnome-keyring, while starting my terminal from a folder in Thunar file manager yields a shell with SSH_AUTH_SOCK not set at all.

I haven't read the recently released patch yet, so I don't know what it's supposed to do, but it sure looks like it got rid of the ssh-agent instance that I thought I had disabled long ago (great!). That still leaves the problem of why SSH_AUTH_SOCK isn't propagating into my terminal when launched from my file manager.

Revision history for this message
Roger Peppe (rogpeppe) wrote :

I just encountered this problem and eventually found this bug.
I see exactly the behaviour described above - starting a terminal with
ctrl-alt-T gets the correct SSH_AUTH_SOCK, otherwise it's wrong.

dpkg -s gnome-keyring confirms that the fix above is
already running on my system:

% dpkg -s gnome-keyring
Package: gnome-keyring
Status: install ok installed
Priority: optional
Section: gnome
Installed-Size: 3572
Maintainer: Ubuntu Developers <email address hidden>
Architecture: amd64
Multi-Arch: foreign
Version: 3.10.1-1ubuntu4.1
Depends: dconf-gsettings-backend | gsettings-backend, libc6 (>= 2.15), libcap-ng0, libdbus-1-3 (>= 1.1.1), libgck-1-0 (>= 3.3.90), libgcr-base-3-1 (>= 3.8.0), libgcrypt11 (>= 1.5.1), libglib2.0-0 (>= 2.37.3), libgtk-3-0 (>= 3.0.0), gcr (>= 3.4), dbus-x11, p11-kit (>= 0.16), libcap2-bin
Pre-Depends: multiarch-support
Recommends: libpam-gnome-keyring, libp11-kit-gnome-keyring
Breaks: libgnome-keyring0 (<< 3.0), seahorse-plugins (<< 3.0)
Conffiles:
 /etc/xdg/autostart/gnome-keyring-pkcs11.desktop 784b3d1e0681f9bb3c8e88a5dd647f0b
 /etc/xdg/autostart/gnome-keyring-gpg.desktop 36f92b6ee1ec39fd7a66800ed344b982
 /etc/xdg/autostart/gnome-keyring-ssh.desktop 2524e326e3413945eabe06dabadb75e5
 /etc/xdg/autostart/gnome-keyring-secrets.desktop 6bbabf4d27046c3bbd4c9081bd9abc4c

Revision history for this message
David Lechner (dlech) wrote :

For those of us that don't want to use gnome-keyring-ssh and use ssh-agent instead, this breaks our setup.

Previously, we were able to disable gnome-keyring-ssh by ediing /etc/xdg/autostart/gnome-keyring-ssh.desktop and setting NoDisplay=false. Then it would be visible in Startup Applications Preferences and you could turn it off. (For mre details and screenshots, see https://github.com/dlech/KeeAgent/issues/89#issuecomment-63449092)

However, now even though gnome-keyring-ssh is disabled at startup, these new changes cause it to run anyway. What is the new way to disable gnome-keyring-ssh?

Revision history for this message
Gunnar Thielebein (lorem-ipsum) wrote :

I am using gnome-keyring-daemon with ssh-agent capability which broke with the keyring-daemon 3.10.1-1ubuntu4.1.
After downgrading to gnome-keyring=3.10.1 SSH_AUTH_SOCKS is again correctly exposed to the keyring location.

Revision history for this message
Vlad Orlov (monsta) wrote :

Here's the list of the regression bug reports caused by this update so far:

https://bugs.launchpad.net/bugs/1387747
https://bugs.launchpad.net/bugs/1388259
https://bugs.launchpad.net/bugs/1391775
https://bugs.launchpad.net/bugs/1412624

Please comment and/or click on "affects me" there instead.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Please stop filing duplicate bugs.
The regression was fixed in vivid a long time ago and is tracked to be SRUed again in

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1387303

Mathew Hodson (mhodson)
tags: removed: ubuntu-desktop-trusty
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.