GNOME Bugzilla – Bug 711222
libpam-gnome-keyring: does not ensure gnome-keyring-daemon is dead before exit
Last modified: 2014-09-01 14:00:03 UTC
It looks like this bug affects trunk as well. Downstream report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728312 Scenario: the user has a homedir mounted via pam-mount (eg. encrypted) and is using pam-gnome-keyring. The problem: on login libpam-gnome-keyring starts gnome-keyring-daemon which opens a named socket in the user's homedir at ~/.cache /keyring-xxxxxx/control. On logout libpam-gnome-keyring sends SIGTERM to gnome-keyring-daemon and returns immediately. pam-mount will at this point attempt to umount the homedir, which will fail if gnome-keyring-daemon is still alive (because it still has the named socket open). pam/gkr-pam-module.c stop_daemon() sends SIGTERM to the gnome-keyring-daemon process instead of SIGKILL ie. just requesting shutdown and ensuring the process is really dead. This means that when pam_gnome_keyring.so returns from pam_close_session() the daemon is sometimes still running (race condition). Since the daemon has an open socket in the users home directory, pam_mount's umount call will fail. This was observed under lightdm and XFCE, but should also affect other systems that use pam-gnome-keyring and pam-mount together. Fix: replacing SIGTERM with SIGKILL in the source fixes the issue. You may want to use SIGTERM/sleep/if(alive) SIGKILL to give the daemon a chance to exit properly.
(In reply to comment #0) > Fix: .... You may want > to use SIGTERM/sleep/if(alive) SIGKILL to give the daemon a chance to exit > properly. This sounds good. I would review/merge such a patch.
How about using XDG_RUNTIME_DIR instead?
I think we do. This is in version 3.12.x ... and should fix your problem. commit 275a696131e41ea4be3d3ddf6690b8bcd0fe0105 Author: Stef Walter <stefw@gnome.org> Date: Thu Mar 6 08:44:47 2014 +0100 daemon: Use $XDG_RUNTIME_DIR to create keyring socket directory We create a predictable location under $XDG_RUNTIME_DIR. GNOME does not support multiple GUI sessions per user, so using a predictable directory works well for us. If someone somewhere still wants an alternate location use the --control-directory argument. https://bugzilla.gnome.org/show_bug.cgi?id=725801 *** This bug has been marked as a duplicate of bug 725801 ***