HOW REMOTE X SERVERS AND CLIENTS COMMUNICATE

Suppose that you are physically in front of HOST1 and using this system as your primary desktop. Then, you remotely log in to a command-line shell (bash or tcsh) on HOST2 using secure shell (hopefully not the less secure telnet!). You can tell HOST2 to use HOST1 for graphical application display by specifying it on the command line of the X application you're running:

 HOST2% xemacs --display HOST1:0.0

You can force all X applications to use HOST1 for display by setting a DISPLAY environment variable within the shell. So in your HOST2 shell you'd use the following commands for a Bourne shell (typically the default on Linux and BSD systems),

 HOST2% DISPLAY=HOST1:0.0; export DISPLAY

or use this command for C shells (the default for Mac OS X):

 HOST2% setenv DISPLAY HOST1:0.0

Normally, you expect a command to execute on the system on which it was run. In the case of a remote X-based application, you still want the application to execute within the context of the remote server, HOST2, but you want to see the output on your localhost, HOST1. Once you have changed the DISPLAY variable, xemacs will attempt to display itself on HOST1. Without the modified DISPLAY variable, the X client would have popped up on the screen of HOST2much to the surprise of anyone currently using it! The flow of the X client/server model is illustrated here.

What does the :0.0 mean after the HOST1 string in the DISPLAY variable? A single host can conceivably run multiple X servers. Each X server can control multiple screens. The format of the DISPLAY variable is as follows :

 DISPLAY = <hostname>:<displaynumber>.<screennumber>

where hostname indicates the name or IP address of the host running the X server, displaynumber indicates which X server the X clients should use, with 0 being the first, and screennumber indicates which screen on the X server should be used, with 0 being the first.

Unless you're using an interesting X server configuration, your DISPLAY will almost always be :0.0 . In fact, you can leave off the .0 part because it assumes screen 0 by default.

X servers listen on TCP port 6000 by default. If a second X server (a display) was run on the same box, it would listen on TCP port 6001. The display number that the X server is using can always be mapped to the corresponding TCP port by adding 6000 to the display number.

Tip	Secure Shell actually handles the `DISPLAY` variable for you, but it's important to understand how X clients and servers interact. Check out the next section for information on further securing X.

You may see a bit of a security problem in this client/server model. Setting the environment variable let us tell the client on HOST2 to display on HOST1. But what's stopping you from sending the display of the application elsewhere? One of the most popular "hacks" in security training classes is setting your DISPLAY variable to your neighbor's X server and watching with amusement as you run numerous instances of xeyes all over his Desktop while he's trying to do work. A more frightening abuse would be to run a program that captures your neighbor's keystrokes from the X server and sends them, passwords and all, to you. Obviously, X servers must have some kind of access control so that only authorized clients are able to display themselves .