Under IRIX 5.1.x or earlier, don't try. The MIT-MAGIC-COOKIE-1
  protocol did not work, and DGL programs did not understand X
  authorization.

  Under IRIX 5.2, heed the wise words of Mark Kilgard of SGI's
  X Window Systems group <mjk@hoot.asd.sgi.com>:

  The basic mechanism for the MIT-MAGIC-COOKIE-1 authorization protocol
  is implemented by the X server, Xlib, and xdm, and does work in IRIX
  5.x.  MIT-MAGIC-COOKIE-1 is the only supported protocol.

  Two caveats before I describe how to enable X authorization:

  1) Old remote IRIS GL programs probably will not be able to connect to
     the X server when X authorization is enabled. (More on this below.)

  2) Due to a problem with how the local hostname is handled, to use X
     authorization in the IRIX 5.x releases, you will need to make sure
     your /etc/sys_id file has a simple hostname, ie. hoot instead of a
     fully resolved hostname like hoot.asd.sgi.com  This problem has
     already been fixed for the next general release of IRIX.

  TO ENABLE X AUTHORIZATION, do the following to your IRIX 5.2 system:

      1)  Edit /var/X11/xdm/xdm-config as root and change the line
      saying

  DisplayManager*authorize:               off

        to say

  DisplayManager*authorize:               on

      2) Edit /var/X11/xdm/Xsession, /var/X11/xdm/Xsession-remote, and
	 /var/X11/xdm/Xsession.dt as root and change the line saying

  /usr/bin/X11/xhost +

         to say

  #/usr/bin/X11/xhost +

         This disables the "xhost +" by commenting out the command.

      3) Make sure your /etc/sys_id file has no periods in it.  For
	 example, change as root:

  hoot.asd.sgi.com

         to say

  hoot

      4) Reboot the machine OR restart a new xdm and X server.  This
	 can be done as root with the following command:

  (/usr/gfx/stopgfx; killall xdm; /usr/gfx/startgfx) &

      5) Log in.  X authorization should be enabled.

  If you want to disable X authorization and return to the default
  system state where X clients can connect to the X server from any
  machine, reverse the changes in steps 1 and 2 and repeat step 4.

  If you want more information on X authorization, see the manpages for
  xdm(1), Xserver(1), Xsgi(1), Xsecurity(1), xauth(1) and xhost(1).

  X AUTHORIZATION AND REMOTE IRIS GL PROGRAMS: One of the major reaons
  for Silicon Graphics shipping its window system so that an X client
  from any machine could connect to the X server was because IRIS GL
  programs running remote using the DGL (distributed GL) protocol didn't
  interoperate with the X authorization mechanism; the dgld daemon that
  would run on the machine with graphics hardware had no way to get the
  correct X authorization information to connect to the X server.

  This has been fixed for IRIX 5.2, but the fix only applies to IRIX 5
  binaries running remotely on an IRIX 5.2 system connecting to an IRIX
  5.2 X server.  In particular, remotely run IRIX 4 IRIS GL binaries
  will continue to not interoperate with an IRIX 5.2 X server (or a
  pre-IRIX 5.2 X server).  If you recompile your old IRIS GL binaries
  on IRIX 5.2, they then will work remotely connecting to IRIX 5.2 X
  servers running X authorization.

  The bottom line is that if you want an IRIS GL program to run
  remotely on an X server using X authorization, you need to make sure
  the program is an IRIX 5 binary running on an IRIX 5.2 machine and
  the machine with the X server is also an IRIX 5.2 machine.

  To avoid a possible misconception: IRIS GL programs RUNNING LOCALLY
  (ie, not using DGL) WILL WORK FINE on an IRIX 5.2 system no matter if
  they are IRIX 4 or IRIX 5 binaries. The problem with X authorization
  is only for REMOTE IRIS GL programs.

  Also note that for X authorization to work for remote hosts, the
  remote program must have access to the correct X authorization magic
  cookie (normally read from ~/.Xauthority).  If you don't have a
  shared NFS mounted home directory, you'll probably need to use the
  xauth command to transfer the X authorization magic cookie to the
  remote ~/.Xauthority file.

  THE FUTURE:  Hopefully in the next general release of IRIX, a
  mechanism to enable and disable X authorization using a chkconfig
  option will be supported.  The problem with /etc/sys_id not having
  periods will definitely be fixed in the next general release of
  IRIX.  The problem with pre-IRIX 5.2 X servers and binaries not
  interoperating with X authorization will likely not be fixed. Fixing
  the problem required a DGL protocol extension which both the IRIS GL
  program and dgld must know about; this can't be fixed in already
  shipped software.

  Under IRIX 5.3, do what you did for IRIX 5.2. There is no chkconfig
  option for X authorization. The problem with periods in hostnames is
  still present in 5.3 as such, but is fixed by patch 518. There is a
  bug in NFS3 which truncates ~/.Xauthority files which is fixed by
  patch 216. See also the descriptions of the shared memory hole and the
  putative X authorization weaknesses below under "security-related
  bugs".