andre wrote:
>
> 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
>
Actually, all my users have the $XAUTHORITY stuff commented out; so "su -[mp]"
actually makes the matter worse in that root won't work either in this
situation. Root does work as indicated below without -[mp].
> Try su -m otheruser (although you than get an hole new set of problem. Especially
>for root)
My thinking was that since root does work, and since other non-root users are on
the same machine, that it should be possible to ssh as user1, su user2 and still
have X capabilities like I do with su root... It's not like I'm trying to ssh
from A to B to C...
Poked around in the /tmp/ssh-*/cookies files and it looks like this would take
some coordinated efforts and would likely increase the security risks... I did
manage to get $XAUTHORITY set in a sneaky way; but this confirmed my security
suspicions... Oh well...
Thanks anyway,
Pierre
> >
> > 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
> >
> >
--
Linux (Up 15 days) -- Reboots are for system upgrades... not Windows X^P
Last reboot reason: 02/14/01: testing startup changes for DSL
