On every startup it reads a proxy setting from system/http_proxy and tries to use it. There is no way for the user to change this without gconf-editor; the 'Network Proxy' prefs have no effect.
the 'Network Proxy' pref should affect the keys under /system/http_proxy/* What is the output of: gconftool-2 --get /system/http_proxy/use_http_proxy Ephy should be reading that key to determine using the proxy or not.
I think I've found the problem. Hat->Preferences->Network Proxy does *not* edit the gconf proxy stuff correctly. Running gnome-network-preferences by hand does.
Tracking this down some more, it appears to be because. a) Gnome, when started from GDM, starts a gconfd in /tmp b) terminal runs with login shell, which sets TMPDIR=~/tmp c) gconfd starts again d) fun with two gconfds ensues.
Ok, moving this to gconf and retitling.
... and re-assigning
Ew. Ick. What the heck is setting $TMPDIR=~/tmp ? This isn't going to screw GConf - you're probably seeing two copies of bonobo-activation. We could do the $GCONF_TMPDIR thing that Frederic had a patch for: http://mail.gnome.org/archives/gconf-list/2003-October/msg00026.html But that'll only fix it for GConf, not bonobo-activation etc.
~/.bashrc is setting TMPDIR. The question is why that isn't in the environment when running from GDM.
How does gnome deal with .PAC files for proxy settings?
Sorry, that was supposed to be in another bug. Don't remember which one.
Discussing with Bill, we aren't fans of ignoring TMPDIR; we should do the root cause thing and track this down to xinitrc/gdm and why the env variable isn't set from the beginning.
So the root problem is TMPDIR is automatically stripped from the environment before execing setgid binaries, and ssh-agent is setgid. The easiest fix (I think) is to modify /etc/X11/xdm/Xsession to use the alternative method of invoking ssh-agent, which is doing `eval ssh-agent -s` before the exec calls.
Reassigning to X maintainers
Well, you still need the login shell fix.
Created attachment 105490 [details] A patch A patch implemeting this fix. I don't have access to the upstream of xinitrc, and I'd prefer if Mike would glance over it to if it is looks basically sane.
Ok, the eval `ssh-agent -s` should be eval `$SSH_AGENT -s`
To get the TMPDIR, you need to change Xclients from: #!/bin/bash to #!/bin/bash -l
Hi Bill, note that /etc/X11/xdm/Xsession calls Xclients like so: exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH $HOME/.Xclients" using #!/bin/bash -l is bad because it will source the .bash_profile/.bashrc in users' homedirs even if they have their login shell set to something else. Not sure how I NOTABUG'd this, meant to reassign.
True. However, setting the -l on Xclients actually avoids the need for the ssh-agent hack. Either or, I suppose.
This type of change seems overly risky at this late in the development cycle. Last minute xinitrc changes wont get adequate end user testing to know if they both fix the problems *and* do not break anything. Every time in the past that we have changed xinitrc at the last second it has caused great pain once the OS is released. Also, every previous OS has shipped with this like it is now, so I don't see how this can be a blocker bug. IMHO, this is a "would be nice to fix, but the risks involved to make these changes at this point are too great and we wont get proper testing". We need to include Kevin in on the decision for this and discuss the specific risks involved and wether the benefits outweigh the risks or not. My personal opinion currently is that this can wait for FC4 development to open up, or if we really do have to fix it, we need to have adequate testing by a large number of people so we don't have things blow up in our faces when FC3 ships. Feedback appreciated. TIA
ssh-agent wasn't previously setgid in any release, so the previous code would have worked fine. It's only broken for FC3 and later.
Hi Bill, setting -l in Xclients isn't really an ideal solution because it means that 1) two login shells are started so sh startup scripts are gettings sources twice 2) all the other exec code paths in /etc/X11/xdm/Xsession won't be fixed and thus will have TMPDIR stripped from their environment
Bill: Ah, ok. I'll investigate the ssh thing tomorrow.
Related bugs for reference: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=7860 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=20781 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=50678 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56822 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=59001 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=59003 "Note that tcsh explicitly disallows the use of -l and -c together, and only the "-" as argv[0][0] method can make it happen. Clearly it was not intended to be used this way." After reviewing all the bugs in bugzilla that are similar, while it wasn't immediately obvious, it seems this type of issue has been bouncing around back and forth every couple of OS releases, where we change the behaviour for one bug, creating one or more new bugs that can only be fixed by changing it back, having previously forgotten about why we changed it a couple OS releases before that. ;o) So, if we are going to make these types of changes again right now, we will be just flipping the switch for which bugs we want to have. I think that the "solutions" that are always presented are just looking at the one particular issue being reported and ignoring previously reported issues. We really need a solution that solves all cases, not just the one being reported at a particular time. I can't see an obvious fix that solves this problem and allows people to use tcsh, with no side effects, but if someone else has a solution they believe solves all of the above bugs without creating a new one, please attach a unified diff with explanation for review, and the X Devel Team will discuss it and try to come up with a solution. Thanks in advance.
Created attachment 105548 [details] Soeren's fix, updated Here's Soeren's patch. I was wrong, the adding of -l is not needed. This is correct because it maintains the use of ssh-agent, withuot having it clear the environment for all subprocesses. The other change from his previous patch is not removing the lines in xinitrc that called ssh-agent/dbus; I believe you still want to call dbus-launch here.
About these: - exec $SSH_AGENT $DBUS_LAUNCH $HOME/.Xclients || \ + exec $DBUS_LAUNCH $HOME/.Xclients || \ exec $DBUS_LAUNCH $HOME/.Xclients I think you may have overlooked the "|| \" at the end of the line. Basically what it does currently is if (!(ssh_agent dbus Xclients)) { dbus XClients } ie., if we don't have ssh_agent, try with dbus. With the eval `ssh-agent -s`, we don't have to care at that point whether we have ssh-agent, so we just run "dbus Xclients". So basically we do still call dbus-launch.
The previous version had: if [ -f $HOME/.Xclients ]; then - exec $SSH_AGENT $DBUS_LAUNCH $HOME/.Xclients || \ exec $DBUS_LAUNCH $HOME/.Xclients elif [ -f /etc/X11/xinit/Xclients ]; then - exec $SSH_AGENT $DBUS_LAUNCH /etc/X11/xinit/Xclients || \ exec /etc/X11/xinit/Xclients else The first part (removing the line) makes sense... the second part I'm not so sure about.
Ah, right. So what we want is actually if [ -f $HOME/.Xclients ]; then - exec $SSH_AGENT $DBUS_LAUNCH $HOME/.Xclients || \ - exec $DBUS_LAUNCH $HOME/.Xclients + exec $DBUS_LAUNCH $HOME/.Xclients || \ + exec $HOME/.Xclients elif [ -f /etc/X11/xinit/Xclients ]; then - exec $SSH_AGENT $DBUS_LAUNCH /etc/X11/xinit/Xclients || \ + exec $DBUS_LAUNCH /etc/X11/xinit/Xclients || \ exec /etc/X11/xinit/Xclients right?
Created attachment 105552 [details] the updated updated patch Yeah, that looks right.
Ok, this patch looks pretty good to me, and also reviewed by a couple others who think it looks right too. I'm committing it to the next xinitrc build.
Ok, upon applying the patch, I noticed the code can be further cleaned up and some redundancy removed. The SSH_AGENT variable is not used anywhere anymore except the one code block, and the two sections can be combined and simplified. SSH_AGENT= [ -x /usr/bin/ssh-agent -a -z "$SSH_AGENT_PID" ] && SSH_AGENT="/usr/bin/ssh-agent" if ! [ -z $SSH_AGENT ] ; then eval `$SSH_AGENT -s` fi Becomes simply: # Start up ssh-agent if available and not already running. [ -x /usr/bin/ssh-agent -a -z "$SSH_AGENT_PID" ] && eval $(/usr/bin/ssh-agent -s) I'm committing this fix.
xinitrc-4.0.14-1 contains the above fixes and is built internally. Please test and provide feedback, and change status to RAWHIDE or ASSIGNED. TIA
Fixes the issue in my test environment - looks good!
I think the changes here have given rise to bug #138747 / bug #139372 ...
Created attachment 108291 [details] ssh-agent prefix to launching session I've commented on bug 139372 with a proposed fix for yet another bug (to add to the list in comment 23 of this bug) that has been introduced by these pull-this-way/push-that-way xinitrc changes (i.e.: fix one thing, break another). It I think will at least allow the fixes implemented in this bug to be preserved and also fix the ssh-agent-hanging-around bug. I will attach a patch to xinitrc, but I'll warn first that it re-introduces the SSH_AGENT variable. I looked at the list of bugs in Mike Harris' comment 23 of this bug and couldn't see any way this would re-introduce any of them, but I am open to correction. It's not proactively fixing any of those bug either, but it allows TMPDIR to still be propogated to gnome-session (or whatever) and dbus-launch (if necessary?) without leaving stray ssh-agent processes around, which, though maybe not major, is a bit of a security concern. (Using ssh-agent on a multi-user box is a security concern in itself [potentially], but that's a whole other discussion.)
Comment on attachment 108291 [details] ssh-agent prefix to launching session skip that patch. That'll teach me to post a patch before trying it out. Session seems to hang and I never get my desktop when I login. This is trickier than Hmm. I thought.
Now ssh-agent doesn't terminate when the user logs out. When previously doing /usr/bin/ssh-agent command ssh-agent would automatically die when command terminated. There ought to be a if [ -n "$SSH_AGENT_PID" ]; then kill "$SSH_AGENT_PID" fi during the logout sequence, either in /etc/X11/xdm/Xsession or a subshell thereof. I think this means removing the exec's from /etc/X11/xdm/Xsession.
Created attachment 109553 [details] second attempt at fixing lingering ssh-agent problem Okay, this one's tested. Again, this doesn't proactively fix the bugs Mike Harris listed, but I don't think it re-introduces any of them that have been fixed. Anyone else want to try it, please? I'm using it without any obvious problems.
This patch looks good to me. ssh-agent is started, if TMPDIR is set in ~/.bashrc then it is set within a non-login gnome-terminal (if not then it doesn't exist), SSH_AGENT_PID points to a correct ssh-agent and ssh-add appears to work. After logging out ssh-agent is gone. Also if X crashes or is killed then ssh-agent still quits. Please roll this out.
There's still something odd about /etc/X11/xdm/Xsession (and some redundancy). From the default Xsession for Fedora 3 this bit of code: 42 # now, we see if xdm/gdm/kdm has asked for a specific environment 43 case $# in 44 1) 45 if [ -x "$SWITCHDESKPATH/Xclients.$1" ]; then 46 exec -l $SHELL -c "$SWITCHDESKPATH/Xclients.$1"; 47 fi; short-circuits many of the cases below it because /usr/share/switchdesk has an Xclients file for gnome, kde and twm (as well as a lot of other window managers you might install). In fact gnome is started with gnome-session and kde with startkde so they don't match either that condition or the specific cases below it but fall through to the default case: 63 *) 64 # GDM provies either a command line as the first argument or 65 # provides 'failsafe', 'default' or 'custom'. KDM will do the 66 # same at some point 67 if [ "$1" != "default" -a "$1" != "custom" ]; then 68 exec -l $SHELL -c "$DBUS_LAUNCH $1" 69 fi I'm wondering if the first bit of code should also be patched to ensure that all Window managers get started properly no matter how they're selected: 42 # now, we see if xdm/gdm/kdm has asked for a specific environment 43 case $# in 44 1) 45 if [ -x "$SWITCHDESKPATH/Xclients.$1" ]; then 46 exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH $SWITCHDESKPATH/Xclients.$1"; 47 fi;
Could bug 149475 be possibly related to the change introduced in this bug?
Someone just brought this bug to my attention, indicating there are patches here that haven't been applied and asking why. There are patches here that haven't been applied, because the bug is in a "CLOSED" state, so we'll never see them until someone reopens the bug by setting the status to "ASSIGNED", or in this case, until someone points the problem out in a different bug report. ;o) To avoid future confusion, please remember "MODIFIED" state means "We believe this issue is fixed, but if it is not, set the bug back to ASSIGNED and we will re-investigate, otherwise we will assume it is indeed fixed and 'CLOSED' The problem reporter(s) in the given bug, are to test the fix, and if the problem is solved, to change the bug to "RAWHIDE" or whatever is appropriate for the given issue. If the bug still exists, indicating the fix did not work properly, the people having the problem need to change the bug state back to "ASSIGNED", effectively reopening the issue. Now that someone has brought the patch from comment #37 to my attention, I am applying it to the next xinitrc build. Hopefully it solves the problem and does not reintroduce any new ones. Setting status to "RAWHIDE".
This also solves the ssh-agent, gconf issue here (and shows no side effects;-). I only see some gam_server processes will keep running even after a user logs out from x11. Please roll this out for rhel 4 as well.
Hmm... The fix of this bug is just opening another with more problems. (See also 148945, and this not only on fedora as also on EL4.) There are two possible solutions I can imagine: 1. Just remove the sgid from ssh-agent (I see no reason why it have the bit) or 2. Change the way dbus and ssh-agent is started (exec $DBUS_LAUNCH $SSH_AGENT ...) The way ssh-agent is started in WS4 is not acceptable!