X Windows General Reference
What is X Windows, and how do I use it?
X Windows provides the basic graphical interface to
our Linux systems. It allows you to run graphical applications on your ltsp,
or remotely, displayed on your desktop.
If for some reason you don't see a graphical login window
on an ltsp, please contact your PoC
with details of the problem. Once you
have logged in, your window manager will start
up, assuming that you haven't disabled it. The window manager customizes and
facilitates your interface to the operating system through the graphical user
interface.
X Windows settings
Ltsps are deployed with settings like refresh rate, resolution, color depth
and screen orientation configured by CSLab. For most machines, the settings we
choose are an optimal mix of all these variables. Many modern computers use
onboard video chips that have memory limitations. These limitations constrain the
refresh rate at high resolutions, making the display appear to flicker. We try
to evaluate the ideal settings based on monitor size, video chip capability, and driver
support. Sometimes a monitor is replaced with a different model and the resulting
display does not look as good, or sometimes indiviual users have very low tolerances for
screen flicker. If you think that your display is not as good as it could be, or
if you wish to try a lower resolution to get a higher refresh rate, please talk to
your Point of Contact person.
If a display cannot be made to perform to meet your expectations, you will need to
discuss with your supervisor the purchase of newer hardware.
Customizations like multiple screen displays or rotated displays can be time consuming
to configure, and may be impossible with your current video hardware. Please send requests
for special customization to your Point of Contact person.
X Windows authentication
There are two mechanisms by which our application servers will allow client programs to
connect to the X servers running on them; host-based (xhost) authentication, and MIT-magic-cookie (xauth)
authentication. Host-based authentication is not safe to use in a multi-user environment,
and neither mechanism is safe to use across untrusted networks without adding some form
of encryption, such as ssh.
Host-based authentication
Xhost authentication allows any client on a given host to connect to your X server. In a
multi-user environment, this is generally a very bad idea, since it lets any user who
has an account on the permitted machine to run programs on your X server. (Even worse,
it is possible to set up an xhost access list which allows any host on the Internet to
connect to your X server!)
This is a serious security issue, since a program that can connect to your X server
can do things like view what's on the workstation's screen, or even send keyboard
events to your windows to run arbitrary commands just as if you had typed them yourself.
For this reason, we strongly discourage all users from using the xhost mechanism at all.
MIT-Magic-cookie authentication
Another way to control who is allowed to connect to your workstation is through the
"xauth," or "magic cookie," mechanism. This is the method that's used automatically
when you run X programs on CSLab computers.
Whenever you log in on an X workstation, the X server generates a "magic cookie,"
which gets stored in your .Xauthority file in your home directory. When you run an
X client program such as "xterm," the program reads the magic cookie from your .Xauthority
file and presents it to the X server, which then knows that the program is allowed to
connect. (Since the permissions on your .Xauthority file are set up so that only you
can read it, this prevents other people from connecting to your X server.)
Because all the CSLab machines can read your home directory (and hence your .Xauthority
file), programs you run on the CSLab servers can automatically connect to your workstation.
For instance, if you run "xterm" from apps0.cs, it can use your display (even though you
haven't used xhost to permit connections from apps0.cs).
However, machines outside the lab (for example, at CDF) can't read the magic cookie
from your CSLab home directory, so they are not allowed to connect to your display.
Forwarding X using SSH
It is important to note that the magic cookie is not encrypted in any way when you run
an X client on a remote machine to open windows on your X display. This means you should
not run X clients over untrusted networks, since anyone who can intercept the packets
between the client and the server can then steal the cookie and use it to connect to
your X server. (For this reason, we generally do not allow such X connections through
our firewall.)
The ssh program can be used to encrypt session and X11 traffic between hosts. If the
remote system has the ssh daemon available, and permits X11 proxying, you can use ssh
to forward X11 connections over an encrypted channel. For example, to open a window
on CDF's server, you can simply run the command:
example% ssh -f mycdflogin@cdf.toronto.edu xterm
You can run X programs in the xterm window that pops up.
See the ssh man page for details. If the ssh daemon is not available at the remote site,
ask their system administrator to install it for you.
By the same token, you should also be using ssh for your login sessions across
untrusted networks; remember never to type your password in the clear (unencrypted) over
the Internet, for instance, in a telnet, rlogin, or ftp session. Otherwise, your password
could be stolen, and your account broken into.
As mentioned above, authentication information for your display is kept in a file in
your home directory called .Xauthority. When SSH sets up X11 forwarding for your session,
it needs to modify this file on the server. In some cases, making these changes to the
file from multiple machines can result in side effects which can prevent programs from
being started correctly.