Bugzilla – Bug 383353
/etc/X11/xdm/sys.xsession makes the pam-launched gnome-keyring useless
Last modified: 2008-08-13 10:55:47 UTC
With the latest Factory update, I now have to enter my keyring password when an application is accessing it the first time. mblxsrv01:/etc/pam.d # cat gdm #%PAM-1.0 auth include common-auth account include common-account password include common-password session required pam_loginuid.so session include common-session session required pam_resmgr.so auth optional pam_gnome_keyring.so auto_start session optional pam_gnome_keyring.so Not sure how to troubleshoot. Please advise.
Found this in /var/log/messages Apr 24 23:37:23 mblxsrv01 gnome-keyring-daemon[10278]: couldn't read 4 bytes from client:
*** Bug 388233 has been marked as a duplicate of this bug. ***
For reference, http://live.gnome.org/GnomeKeyring/Pam is useful here :-) It seems that on login, we have two gnome-keyring-daemon running. One from PAM (I guess) which automatically unlocks the keyring (all is well) and another one. The other one seems to be "hiding" the first one, so it's as if the keyring was unlocked. Maybe it's started by gnome-session, but there's code in gnome-session to not start a second daemon if one is already there. Next step: confirm how the two daemons are started.
Looks like the gnome-keyring socket that is supposed to be created by the pam-launched gnome-keyring-daemon doesn't exist. Which explains why gnome-session starts a new daemon.
Okay, that's not a gnome-keyring issue, but a problem in how we handle ssh-agent in /etc/X11/xdm/sys.xsession: if test -S "$SSH_AUTH_SOCK" ; then if test -n "$SSH_AGENT_PID" && checkproc -p $SSH_AGENT_PID $sshagent ; then export SSH_AGENT_PID SSH_AUTH_SOCK else rm -f "$SSH_AUTH_SOCK" case "${SSH_AUTH_SOCK%/*}" in /tmp/*) rm -rf "${SSH_AUTH_SOCK%/*}" esac unset SSH_AUTH_SOCK fi else unset SSH_AUTH_SOCK fi That's assuming that the ssh agent is setting SSH_AGENT_PID and that the binary is called ssh-agent, which is wrong for gnome-keyring. So the gnome-keyring directory containing the socket is deleted. A potential fix is explained in bug 389896. If this proposed fix is considered too intrusive, a simpler fix might be to check for the existence of GNOME_KEYRING_PID and gnome-keyring-daemon in addition to SSH_AGENT_PID and ssh-agent.
Werner is here our expert as well.
In other words if the variables GNOME_KEYRING_PID and GNOME_KEYRING_SOCKET are set, the process for the pid found in GNOME_KEYRING_PID is /usr/bin/gnome-keyring-daemon and we have a valid socket, the ssh-agent should be skipped? then this piece of code # # No ssh-agent if a ssh session is already provided by an other agent. # if test -n "$GNOME_KEYRING_PID" -a -S "$GNOME_KEYRING_SOCKET" ; then if test -S "$SSH_AUTH_SOCK" ; then usessh=no fi fi before setting up ssh-agent should work. The question is if the variable GNOME_KEYRING_SOCKET holds the path to a real socket file.
(In reply to comment #7 from Dr. Werner Fink) > In other words if the variables > GNOME_KEYRING_PID > and > GNOME_KEYRING_SOCKET > are set, the process for the pid found in GNOME_KEYRING_PID is > /usr/bin/gnome-keyring-daemon and we have a valid socket, the > ssh-agent should be skipped? > > then this piece of code > > # > # No ssh-agent if a ssh session is already provided by an other agent. > # > if test -n "$GNOME_KEYRING_PID" -a -S "$GNOME_KEYRING_SOCKET" ; then > if test -S "$SSH_AUTH_SOCK" ; then > usessh=no > fi > fi > > before setting up ssh-agent should work. The question is if the > variable GNOME_KEYRING_SOCKET holds the path to a real socket file. It does, yes. I'm just not sure you need to check that it's a socket file since it's unrelated to the ssh-agent part of gnome-keyring-daemon. Note that it might make sense to distribute this in the gnome-keyring package and install a file in /etc/X11/xinit/xinitrc.d/ if files there are sourced during the login.
For this particular piece this is not required. This could be an option for seahorse. Nevertheless, why should a none GNOME user be disturbed by an other agent. Is there any chance to detect if within an gdm session (environment variable GDMSESSION set) a none GNOME session. I need a test case like if test test "$usegpg" = yes -a "${WINDOWMANAGER##*/}" = "gnome-session" [...] usegpg=seahorse fi to switch over to seahorse.
Werner, Please set vuntz@novell.com for NEEDINFO instead of reporter :-)
(In reply to comment #9 from Dr. Werner Fink) > For this particular piece this is not required. This could be an option > for seahorse. Nevertheless, why should a none GNOME user be disturbed by > an other agent. 100% agree, it should only be used within GNOME. > Is there any chance to detect if within an gdm session > (environment variable GDMSESSION set) a none GNOME session. > > I need a test case like > > if test test "$usegpg" = yes -a "${WINDOWMANAGER##*/}" = "gnome-session" > [...] > usegpg=seahorse > fi > > to switch over to seahorse. As far as I can tell, the only reliable thing we can rely on is WINDOWMANAGER="/usr/bin/gnome" Note that it's seahorse-agent (seahorse is the app to manage the keys).
AFAICS from http://live.gnome.org/Seahorse/SessionIntegration and the source code seahorse edits the file ~/.gnupg/gpg.conf (which is a bug IMHO) ... beside this seahorse should be started *after* the process which has created the socket $SSH_AUTH_SOCK. The question is: does the option '--variable' obmit editing ~/.gnupg/gpg.conf? This is given at http://live.gnome.org/Seahorse/SessionIntegration but the souce code says: static gboolean display_vars_dummy = TRUE; * This is the default but is kept here for backward compatibility */ { "variables", 'v', 0, G_OPTION_ARG_NONE, &display_vars_dummy, N_("Display environment variables (the default)"), NULL }, and the variable display_vars_dummy is not used at any other place.
Next point, seahorse-agent does not have an --write-env-file option which makes it very difficult to be able to use the same gpg session even for an sub session e.g. started by Xnest.
Created attachment 215156 [details] /etc/X11/xdm/sys.xsession Please test out it this /etc/X11/xdm/sys.xsession will work with both gnome-keyring and seahorse-agent
(In reply to comment #14 from Dr. Werner Fink) > Created an attachment (id=215156) [details] > /etc/X11/xdm/sys.xsession > > Please test out it this /etc/X11/xdm/sys.xsession will work > with both gnome-keyring and seahorse-agent Seems to work fine here. Thanks! There's a small bug: echo "$GPG_AGENT_INFO" > "$GPG_AGENT_FILE" should be echo "GPG_AGENT_INFO=$GPG_AGENT_INFO" > "$GPG_AGENT_FILE" (In reply to comment #12 from Dr. Werner Fink) > AFAICS from http://live.gnome.org/Seahorse/SessionIntegration and the > source code seahorse edits the file ~/.gnupg/gpg.conf (which is a bug > IMHO) ... beside this seahorse should be started *after* the process > which has created the socket $SSH_AUTH_SOCK. > > The question is: does the option '--variable' obmit editing ~/.gnupg/gpg.conf? > This is given at http://live.gnome.org/Seahorse/SessionIntegration but the > souce code says: If I can trust the modification date of ~/.gnupg/gpg.conf, it hasn't been modified here. So it works. An alternative is to use --execute, but it won't do the agent.info file creation. (In reply to comment #13 from Dr. Werner Fink) > Next point, seahorse-agent does not have an --write-env-file option which > makes it very difficult to be able to use the same gpg session even for > an sub session e.g. started by Xnest. Want me to open a bug upstream to get this? Not sure it'll be accepted, but we can try.
It would be perfect if the seahorse would provide similar options like the gpg-agent has. Just submitted a new xorg-x11
(In reply to comment #16 from Werner Fink) > It would be perfect if the seahorse would provide similar options like the > gpg-agent has. http://bugzilla.gnome.org/show_bug.cgi?id=533205
*** Bug 389896 has been marked as a duplicate of this bug. ***
*** Bug 339909 has been marked as a duplicate of this bug. ***
*** Bug 351884 has been marked as a duplicate of this bug. ***
Created attachment 233132 [details] keyring prompt
hello, i have the same situation as described in Description... i have tried this attached file /etc/X11/xdm/sys.xsession and nothing changes for me, so i still get the prompt from my wireless network connection and have to enter password to unlock the default keyring at startup, see screenshot
This bug is closed. Please open a NEW one.
thank you i have opened a new one https://bugzilla.novell.com/show_bug.cgi?id=416942