Description of problem: Fedora Core 3 on i686, fully updated as of 15 Nov 04 morning. Boots into runlevel 3. Login to command prompt. This issue occurs on all users. If icewm is run, upon exiting there is no ssh-agent left running. If the default gnome window manager runs, after exiting to command prompt there is a ssh-agent process left running. If we run the gnome window manager again, and exit to command prompt, another ssh-agent is left running. These will never terminate except by kill -15. Should these exit when the gnome window manager exits? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This looks like a dup of bug 138747
Yes, I would agree that these report the same problem.
Your report says that this is limited only to GNOME. I shall try and test that tomorrow and add that information to my report...
I can add that this also occurs with KDE (my wife uses KDE). But not with icewm (which is my preference because it is lighter and faster). Sorry, but I don't know much about the configuration of window managers.
I suspect you don't see this in icewm because unlike the other environments its start up scripts have not been told to start ssh-agent. On KDE, GNOME, XFCE I can start a shell and type "echo $SSH_AGENT_PID" and see that an ssh-agent has been started for me. I suspect because icewm is a third party package echo $SSH_AGENT_PID will not show anything...
This is a good point, I think. Your testing shows this is not limited to Gnome but that the ssh-agent is also started by Kde and Xfce. I wonder what exactly starts the ssh-agent: is it each of those three or something else that is common to them all? I seems reasonable that once the process is found which starts the ssh-agent, then it should be fairly easy to add a way to close the ssh-agent when the window manager closes. Thanks for pursuing this.
I have answered some of your questions over in bug 138747
I can't seem to find it, but I seem to remember an xinitrc bug that this bug should really be marked a duplicate of, in addition to bug 138747. Anyhow, the change that causes this problem was required due to a bad security configuration that was fixed in openssh. The ssh-agent binary now has its sgid bit set to eliminate the strace-ability (I believe) of the process. The problem is that glibc (or is it ld-linux.so?) strips TMPDIR from the environment when running suid/sgid binaries. This caused problems with either gnome itself or dbus-launch, I forgot which. I think I have a possible solution to this, but would like feedback. It so simple that there *must* be something I'm missing. Try this: ssh-agent /bin/env TMPDIR=$TMPDIR /bin/bash echo $TMPDIR This basically sets the TMPDIR in defiance of glibc unsetting it when launching ssh-agent ;-) I don't know if this has any security implications, or even if it solves the problems mentioned in the bug on xinitrc (sorry, I don't have the bug number), which is what I'm looking for feedback on. Basically what I'm saying is that it may be possible to revert the xinitrc-common changes (well, not all of them as there were some cleanups) to at least prepend "/usr/bin/ssh-agent /bin/env TMPDIR=$TMPDIR" before the dbus-launch invocation.
Hmm interesting stuff. After lots of scouring I think the changes began in bug #134494
Um, skip that 'solution' I suggested. Tried it. Doesn't work. I'll see if I can come up with something that works. Seems like a hairier problem than I thought.
Marking as a dup of bug #138747 which I'll move to xinitrc where the changes in bug #134494 were originally made *** This bug has been marked as a duplicate of 138747 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.