If you su the ~/.bashrc will be "executed". It says use /$homedir/.Xauthority as
$XAUTHORITY. This contains the magic-cookie necassary to connect to the Xserver. The
magic-cookie the new user has are different than the magic-cookies from the old user.
If you try to connect to the Xserver with the new cookies the Xserver wil look at
those new cookies as say i don't no these cookies so piss off
Try su -m otheruser (although you than get an hole new set of problem. Especially for
root)
>
> This is from 7.2; but may also apply to 8.0 (I don't recall seeing a final
> resolution to the issue..)
>
> I've resolved all the XAUTHORITY issues on my system except for one case...
>
> > [pfortin@bones pfortin]$ echo $DISPLAY $XAUTHORITY
> > bones.pfortin.com:10.0 /tmp/ssh-UTXS8974/cookies
> Good.
>
> > [pfortin@bones pfortin]$ su
> > [root@bones pfortin]# echo $DISPLAY $XAUTHORITY
> > bones.pfortin.com:10.0
> XAUTHORITY not set at all; but X/ssh still works for root.
>
> Now... whether I "su otheruser" from root or my own account, X/ssh fails...
> > [pfortin@bones pfortin]$ su pfortin2
> > [pfortin2@bones pfortin]$ echo $DISPLAY $XAUTHORITY
> > bones.pfortin.com:10.0 /home/pfortin2/.Xauthority
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> While /etc/profile.d/xhost.sh appears to _want_ to do the right thing, it
> can't... Why? Because XAUTHORITY is NOT passed with the other env.vars. To
> see this, just add:
> echo "XAUTHORITY=$XAUTHORITY"
> echo `/usr/bin/printenv`
> at the start of /etc/profile.d/xhost.sh
>
> So... anyone know why XAUTHORITY (others?) is filtered by su?
>
> I would like to be able to do X/ssh without opening more ssh paths; is this a
> reasonable wish...?
>
> Pierre
>
>
> Michael Brown wrote:
> >
> > On Thu, 1 Mar 2001, Alexander Skwar wrote:
> > > > don't know. I'll test one day. Did you export the display correctly?
> > > Yes, it's exported automatically, and other X apps work just fine.
> > > <snip>
> > > Hmm, justed tested a bit more, and it seems that this error happens with all
> > > X apps?!?
> > > <snip>
> > > So it's not even an error of the gfx library (gtk/qt), because it happens
> > > with KDE programs as well as with GNOME stuff....
> >
> > I've just spent 15 minutes fixing this problem (it may already have been
> > fixed but I don't have a Cooker to check it on):
> >
> > As part of ssh's X11 authentication spoofing, it sets XAUTHORITY to point
> > to a temporary "cookies" file.
> >
> > At some point since 7.0, a section has been added to /etc/skel/.bashrc
> > that overwrites the XAUTHORITY variable at login. This screws up
> > SSH. (Courtesy of the openSSH web site.)
> >
> > Quick fix: Comment out the line
> > export XAUTHORITY=$HOME/.Xauthority
> > in ~/.bashrc
> >
> > Proper fix:
> >
> > Why is this line even included in ~/.bashrc? XAUTHORITY is already set by
> > /etc/profile.d/xhost.sh, which checks to see if it is already set before
> > overwriting it - so it works happily with ssh.
> >
> > ************************************************************************
> > This line ( export XAUTHORITY=$HOME/.Xauthority ) should be removed from
> > /etc/skel/.bashrc
> > ************************************************************************
> >
> > The next problem is that the offending line was in /etc/skel/.bashrc,
> > rather than e.g. /etc/bashrc or /etc/profile. This means that users
> > existing on a 7.2 system that is upgraded to 8.0 will still suffer from
> > the problem!
> >
> > Ideas for an elegant way to fix this, anyone?
> >
> > Michael
>
> --
> Linux (Up 14 days) -- Reboots are for system upgrades... not Windows X^P
> Last reboot reason: 02/14/01: testing startup changes for DSL
>
>
