For an X client (such as the TotalView debugger) to display on an X-display server (such as your X terminal or workstation), the client must be authorized to connect to the server. Xauth offers an alternative way to manage this authorization. For security reasons, LC does not recommend using xhost .
LC recommends that you use a user-based, rather than a host-based, access control method. User-based access control avoids most of the security deficiencies present with host-based access control. The most common user-based access control method is called MIT-MAGIC-COOKIE-1. This method of user-based access control requires two steps. First, the .Xauthority file in your server's home directory must be set up and supplied with the magic cookie. Second, the .Xauthority file in the remote machine's home directory must be established and given the same cookie. Fortunately, many LC production computers share common home directories. This gives you the convenience of setting up just one .Xauthority file in your common home directory that allows you to open windows on your display from clients running on any of the remote hosts that share that directory.
Xauth is a utility program that manipulates these .Xauthority files (examples follow). Running xauth with no options returns an xauth> prompt. You can respond with a question mark to see a list of xauth commands, or type
to get information on a specific command.
Launch the X-window using either XDM (X display manager) or xinit. The program your system uses determines how much work, if any, you need to do to set up user-based authorization on your server machine.
If you are using XDM, the X server is always running. Start your individual X session by logging in via a dialog box. User-based access control is built into the XDM control protocol. This means that the .Xauthority file will automatically be set up for you and the magic cookie will communicated with your server when you log in. You can skip to the "Setting Up Client Authorization" section.
If you are using xinit, you may have to set up authorization on the server machine yourself. Some window managers, such as OpenWindows, do this for you. If you have a .Xauthority file in your home directory on the server machine, then authorization was probably set up for you. If your home directory lacks a .Xauthority file, you can create one using xauth. First, you must create a pseudorandom number to be used as the magic cookie code. This should consist of an even number of hexadecimal digits. One method of generating a suitable magic cookie is with:
cookie='echo "(obase=16;$$^3)" | bc' [Korn/Bourne shell]
set cookie='echo "(obase=16;$$^3)" | bc' [C shell]
You can add this magic cookie to the .Xauthority file by running xauth twice:
xauth add $(HOST)/unix:0 . $cookie
xauth add $(HOST):0 . $cookie
Then you must start the X server using this code, which can be done by running xinit with a special argument:
xinit -auth $HOME/.Xauthority
After setting up server authorization (see previous section), you must set up the corresponding .Xauthority file on each remote machine where you will be running X clients. First, use xauth on your server (here xyz.llnl.gov) to list the contents of your .Xauthority server file, extract the magic cookie code, and place it in a new file (here called authfile) for exporting to remote client machines:
xyz.llnl.gov:0 MIT-MAGIC-COOKIE-1 e471b4f5a9ed8674fe38bcd2b01f8ab9
xyz/unix:0 MIT-MAGIC-COOKIE-1 e471b4f5a9ed8674fe38bcd2b01f8ab9
xauth extract authfile xyz.llnl.gov:0
Next, move authfile to the remote machine(s) and place it in your home directory (using FTP). If a .Xauthority file does not already exist there, you can just rename your authfile to .Xauthority. If .Xauthority already exists, merge the two files by running xauth on the remote machine:
xauth merge authfile
If for some reason you cannot FTP your extracted cookie file (here authfile) to the remote machine, you can run xauth on the remote machine and add the cookie by hand using an execute line of this form (cut and paste the cookie string to avoid errors):
xauth add xyz.llnl.gov:0 e471b4f5a9ed8674fe38bcd2b01f8ab9
Your X clients on the remote machine can now authorize themselves to display on your X server (here xyz.llnl.gov).
Remember that most LC production computers share common home directories. Setting up one .Xauthority file in your common home directory allows you to open windows on your display from clients running on any of the remote hosts that share that directory, without further use of xauth.