A Brief Tour of the X Display Environment

131
■ ■ ■
CHAPTER 21
A Brief Tour of the X Display
Environment
T
his chapter is not an exhaustive discussion of the X Window System architecture; there
are many books devoted to this topic. I will, however, explain how to send windows to
remote displays. In short, an X-enabled application (xterm, xclock, xeyes, etc.) can be run
from one system and the display (that is, the window) can be viewed on a totally separate
system.
The variants of the Microsoft Windows operating system cannot export the display of
an individual application to be viewed on a separate machine. If an application runs on
one of those systems, the user can see the display only on that system if he is logged in
directly to the console. A separate application, called a remote desktop manager, makes it
possible to view a whole desktop as opposed to an individual application remotely across
the network. X-enabled programs are different in that they have the ability to set display
details at the individual application level. The X Window System (or X) allows a user to run
individual programs on multiple remote systems while viewing them all locally on a single
display. I will demonstrate this functionality in Chapter 22 when discussing the X Naviga-
tion Window.
Now, how is this related to shell scripting? Part of scripting consists of understanding
system capabilities that you can exploit in your scripts. This chapter explains some of
the basic settings and utilities for displaying X client applications that a shell script can
exploit.
The Display
X applications consist of a client and a server. In X, however, the relationship between
clients and servers is confusing because it is quite different from what you might assume.
The X client is an application program, such as xclock or xterm, and the location of the
viewable display is called the server (or display server), since it is serving the application’s
graphical display functions.

132
CHAPTER 21
■
A BRIEF TOUR OF THE X DISPLAY ENVIRONMENT
Some common X servers are XFree86 and X.org on Linux and other UNIX-related oper-
ating systems, and Exceed and Cygwin/X on Windows. There are many more.
Once you have one of these X servers running on your system, you can send to it the
display data of an X-enabled application’s user interface. Let’s assume you’re running an
X server on a laptop and the X application (i.e., client) that you want to run is located on a
remote system. You can arrange to have the application output display on the laptop. The
following paragraphs will shed more light on this scenario.
First you need to understand the DISPLAY variable. The -display option is critical to all
X applications because it denotes the network location to which the display output will be
sent. A display consists of nothing more than a system name or IP address followed by a
colon and a number. An example is ron.mydomain.com:0, which is display 0 on the system
with the domain name ron.mydomain.com. If you are working on the console of a system
that has an X server running and you start an X application on that system, it is not neces-
sary to specify the local system name, as it is the default value. Thus the display for a local
system where the X server and client are both running is commonly called simply :0. An X
server can be configured to have multiple displays, each of which is identified by a num-
ber; zero is the most commonly used as the primary display.
Here is what an invocation of xclock, specifying the display on the command line,
would look like:
/usr/bin/xclock -display ron.mydomain.com:0 &
Another way to set your display is with an environment variable. The environment
variable checked by all X applications when they run to determine the display server is
DISPLAY. If DISPLAY is set correctly prior to running the application, the -display switch
is not required. Setting the value is simple but depends on the shell you’re running:
export DISPLAY=ron.mydomain.com:0
Any X applications started after the DISPLAY variable is set will use that value and the

application window will show up on that X server. Of course, I could set my display vari-
able to rons_friend.mydomain.com:0 and send the application display to that system
instead of to my own. Technically, this is perfectly reasonable. However, while there can
be valid reasons for this action, you can see how it could present you with potential secu-
rity problems.
This brings us to the xhost utility, which gives you the ability to allow or to restrict X
applications from displaying on your X server. This power is traditionally called access
control. The xhost command to limit access has the form xhost [+|-]nodename|username,
where the plus sign allows access and the minus sign disallows access. This gives you fine-
grained control of what systems and users have access to your X server. Using the xhost +
command disables all access control, and any users or systems will be able to send dis-
plays to your X server, although normally this is not what you would want. By default, the
security denies access to those not specifically allowed.
CHAPTER 21
■
A BRIEF TOUR OF THE X DISPLAY ENVIRONMENT
133
X Traffic Through ssh
One of the downsides of X network traffic is that it isn’t secure. A malicious third party
able to view X network traffic can listen in on your sessions and log keystrokes, view the
windows you are viewing, or even hijack the session. This isn’t a good thing. One good
way to tighten up the security of X traffic across the network is to use ssh, the secure shell.
You can use the ssh utility to tunnel pretty much any network protocol across an
encrypted connection, including X traffic. In this case, the insecure X protocol is being
packaged and carried within the secure encrypted ssh protocol. As long as the ssh server
and client are configured correctly, X traffic is tunneled securely but otherwise acts
exactly the same as if there were no encrypted connection. There is a little overhead,
however, since all traffic has to be encrypted before being sent.
You must configure a few settings on the sshd server and the ssh client to implement X
protocol tunneling. The option for X11Forwarding in the sshd_config file should be set to

yes. Then the sshd process should be restarted to enable the new configuration. There is
also an option on the ssh client side to enable X forwarding or tunneling. To enable it from
the command line, you add -X (when using OpenSSH) to the ssh command. However, on
Linux and Solaris systems X forwarding is enabled without using the switch; the Cygwin
ssh client requires the -X switch.
There are many ssh clients, each of which has a number of settings to enable X for-
warding. One popular client is PuTTY, which is a free implementation of telnet and ssh
for Windows and UNIX platforms. Once you have created a session, you enable X forward-
ing by clicking Connection
➤
SSH
➤
X11. There is a check box on this screen to ‘Enable
X11 Forwarding’.
Once the ssh session is configured, you can start your X server then open your ssh
session to the remote system and log in. At that point, you can start an X application
using the ssh session, and the application window will come up on your local X server.
■
Caution
When enabling tunneling under X, there is a file called .Xauthority in the user’s home direc-
tory on the remote system. It contains the authorization information for connecting to the X server. This file
should be readable only by its owner. If another user on the remote system has the ability to read that file, that
user will have access to your display through the forwarded connection. The user may then be able to monitor
keystrokes processed by your X server.
X Applications Through a Third-Party System
As just mentioned, the .Xauthority configuration file contains the authorization for a
specific user to attach to and use a specific display. Suppose you have an environment
comprising various systems that you want to access via the Internet, and you want to
134
CHAPTER 21

■
A BRIEF TOUR OF THE X DISPLAY ENVIRONMENT
use X applications from those systems. However, for security reasons you have ssh
access only through a single portal system, and thus you don’t have direct access to
all of the machines in your environment. What do you do?
If your Internet-facing system has its ssh daemon set as described, then once you open
your initial ssh session you will have a secure connection through which to send X traffic.
Enabling all other systems in the environment to use this secure link is just a matter of giv-
ing them the appropriate authority to link up to the original session.
To make this simple, the following example consists of a three-system environment.
Machine A is the machine you’re working on, and it has an X display server running. The
Internet-facing remote ssh server B is the machine with which you open an ssh session;
this is where you will create a secure tunnel through which to pass X traffic destined for
the X server on A. Machine C is the box behind the ssh server; the ssh server portal
machine can access it, but that machine is not directly accessible from the Internet.
Assume that system C does not have ssh enabled, although there is an X application there
that you need to access.
First, we open an X-enabled ssh session between systems A and B. Then we obtain
the X authority information for that session. You can view this information by running the
command xauth list on system B; it shows you all sessions and displays contained in
your .Xauthority file. Here are a few sample lines from the output on my system:
casper:17 MIT-MAGIC-COOKIE-1 47c872e9b9e62080749e3f6cb601e173
casper:16 MIT-MAGIC-COOKIE-1 d778834a45880121769f333b41a119d1
casper:15 MIT-MAGIC-COOKIE-1 427868f7541d8f1a84538841fd362a3f
casper:14 MIT-MAGIC-COOKIE-1 95bacf26a4e6ab10c6a5bf95ac228ad8
Each record of this xauth output represents a specific display, shown in the first field of
each line. The second field shows the protocol used for creating the token to allow access
to that display. The last field is the 128-bit hex token that is presented to the X server by the
client that authorizes the application to be displayed.
To extract the authority information for the current display in a usable form and send

it to a file called xauth-cookie_file, run the following command:
xauth nextract - $DISPLAY > xauth_cookie_file
The DISPLAY variable is set automatically when the ssh session is opened, so this
should work. Note the DISPLAY value, though. The output from this xauth command
consists of a long list of characters that represents the token for the current session. The
xauth_cookie_file can then be moved to the remote system (Machine C) and merged
into the .Xauthority file on that system. This is done by running the following com-
mand on Machine C after copying the file there:
xauth nmerge - < xauth_cookie_file
To validate the entry that has been added, run the ‘xauth list’ command again, but
this time on Machine C. Now that authorization for Machine C to connect to the display
on Machine A is in place, the last task is to set the DISPLAY variable for the X client on
CHAPTER 21
■
A BRIEF TOUR OF THE X DISPLAY ENVIRONMENT
135
Machine C to use. For this example, we’ll take the last line from the xauth list sample
output shown previously to be our current DISPLAY.
Notice that the display number is 14, instead of 0 as it was earlier.
export DISPLAY=casper:14
Since the ssh server can have many tunneled X sessions attached at the same time, the
display number increases with the number of sessions attached to the ssh server. Also,
when you set the DISPLAY variable, you may need to fully qualify the name of the display
system (Machine B) in order for Machine C to know which system should be attached.
You may recognize a small oddity in that the DISPLAY variable is set to Machine B instead
of Machine A, where the X server is running. This is because you are attaching to one end
of the ssh tunnel. The other end of the tunnel is on Machine A, which is where the appli-
cation is actually displayed.
The authority and display are now set on Machine C. You should be able to run an X
application on Machine C, and its display will be sent to the X session that is being tun-

neled through Machine B via ssh. The display information will travel through the tunnel
and show up on Machine A.
■
Caution
The X traffic traveling between Machine C and Machine B is not encrypted, and the usual
security concerns for unencrypted X traffic should be noted for this connection. Our model assumes that
Machines B and C are part of a single trusted environment, and that the security boundary is between them
and Machine A.
User-Profile Entry
One way to make this procedure a lot simpler is to include commands in the system or
personal profile (i.e., in the /etc/profile or ~/.profile file that runs on login) that create
a file containing the current authorization cookie and the current value of the DISPLAY
variable. Additional code then checks for that file, merges the authorization cookie into
the remote system’s .Xauthority file (using xauth -nmerge), and sets the DISPLAY variable.
This makes the X experience seamless. Keep in mind that security issues relating to
remote file access still apply.
If your home directory is NFS-mounted to a central location, the process is even easier.
All that is required is to add these entries to your personal .profile or .bash_profile. All
the systems in the environment will then have access to the same ssh tunnel session.
You would use the following code in your personal .profile or .bash_profile file in an
environment where home directories are NFS-mounted. The main idea of the code is that
you would create the configuration files that contain the .Xauthority information and the
DISPLAY value when you initially log into the machine used to set up the encrypted tunnel