Re: howto pull the gui.....

[Raja Subramanian <rsubr@xxxxxxxxxxxx>]

M K Saravanan wrote (mksarav@xxxxxxxxxxxxxxxxx):

> > For example, if you have machine A, where you are running an application
> > (say netscape) & you want the program to display the output (the GUI) on
> > machine B, then you do this:
> > Assume (A = 10.10.10.1 & B = 10.10.10.2)
> > 
> > Run X Server on B  (as X :1)
> > Login to A
> > Give the command export DISPLAY=10.10.10.2:1.0
> > Run netscape in A
> 

Here is how I start netscape on a remote machine (queeg) from any local
terminal (all these commands are on the local machine)
    xhost +queeg (do this only once)
    rsh queeg export DISPLAY=$DISPLAY \; /usr/local/bin/netscape

A short rant about xauthority and xhost -
The xauth command creates/manage the MIT magic cookie which is used to
authorize connections to your display. The magic cookie is stored in
~/.Xauthority which is readable only by your programs. If your home dir is
mounted on both machines, you do not need to do the xhost command as the
remote programs have the correct (same) magic cookie as the X server.

By doing an xhost+ command you are disabling access control to your display
<very bad!>. This implies that _any_ client on queeg can connect to my local
display and can spy my keystrokes or any other XEvent.

Solutions -
The `/usr/bin/X11/xon' shell script manages the cookies and runs your command
on the remote host. But the cookies are not encrypted during transit to the
other host (someone snooping your network can capture the cookie).

Note: I just realised that the linux version of xon does not do fiddle with
xauth, if anyone is interested I can post a (homemade) robust xon script.

The ultimate solution is to use ssh and securely forward connections through
an ssh tunnel <which ofcourse requires ssh clients/servers to be correctly
 installed>.
    ssh queeg -X -n /usr/local/bin/xemacs &
runs emacs on queeg securely.

Using ssh is also dangerous because root user on queeg can still spy on my
local X server. Well I guess that this cannot be avoided - if you open an X
connection (anyhow) to an trusted remote machine you are vulnerable :-/

- Raja

PS: I'm sorry that this is a long post, but I felt that there were several
issues which were not addressed by any previous posts.