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!