Sommaire :

1 : X
2 : XHOST
3 : XWD
4 : XSERVER
5 : XSECURITY
6 : XDM
7 : XWUD
8 : SSH2
9 : Xauth

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""


X(1)                                                         X(1)

NAME
       X - a portable, network-transparent window system

SYNOPSIS
       The X Window System is a network transparent window system
       which runs on a  wide  range  of  computing  and  graphics
       machines.   It  should  be  relatively  straightforward to
       build the X Consortium software distribution on most  ANSI
       C and POSIX compliant systems.  Commercial implementations
       are also available for a wide range of platforms.

       The X Consortium requests that the following names be used
       when referring to this software:

                                   X
                            X Window System
                              X Version 11
                      X Window System, Version 11
                                  X11

       X Window System is a trademark of X Consortium, Inc.

DESCRIPTION
       X  Window System servers run on computers with bitmap dis-
       plays.  The server distributes user input to  and  accepts
       output  requests  from  various  client programs through a
       variety of different interprocess communication  channels.
       Although  the  most common case is for the client programs
       to be running on the same machine as the  server,  clients
       can  be  run  transparently from other machines (including
       machines with different architectures and  operating  sys-
       tems) as well.

       X  supports  overlapping  hierarchical subwindows and text
       and graphics operations, on both monochrome and color dis-
       plays.   For  a full explanation of the functions that are
       available, see the Xlib - C Language X  Interface  manual,
       the  X Window System Protocol specification, the X Toolkit
       Intrinsics - C  Language  Interface  manual,  and  various
       toolkit documents.

       The  number  of  programs that use X is quite large.  Pro-
       grams provided  in  the  core  X  Consortium  distribution
       include:  a  terminal  emulator,  xterm; a window manager,
       twm; a display manager, xdm; a console  redirect  program,
       xconsole;  a mail interface, xmh; a bitmap editor, bitmap;
       resource  listing/manipulation  tools,  appres,   editres;
       access  control  programs, xauth, xhost, and iceauth; user
       preference setting programs, xrdb, xcmsdb, xset, xsetroot,
       xstdcmap,  and  xmodmap; clocks, xclock and oclock; a font
       displayer, (xfd; utilities for listing  information  about
       fonts,   windows,   and   displays,   xlsfonts,  xwininfo,
       xlsclients, xdpyinfo, xlsatoms, and  xprop;  screen  image
       manipulation utilities, xwd, xwud, and xmag; a performance
       measurement utility, x11perf; a font compiler, bdftopcf; a
       font server and related utilities, xfs, fsinfo, fslsfonts,
       fstobdf; an X Image Extension exerciser, xieperf;  a  dis-
       play  server  and related utilities, Xserver, rgb, mkfont-
       dir; remote execution utilities, rstart and xon;  a  clip-
       board  manager,  xclipboard; keyboard description compiler
       and related utilities, xkbcomp, xkbprint, xkbbell, xkbevd,
       xkbvleds,  and  xkbwatch;  a utility to terminate clients,
       xkill; an optimized X protocol proxy, lbxproxy; a firewall
       security  proxy,  xfwp;  a  proxy manager to control them,
       proxymngr; a utility to find proxies, xfindproxy; Netscape
       Navigator  Plug-ins,  libxrx.so  and  libxrxnest.so; an RX
       MIME-type helper program, xrx; and a utility to cause part
       or all of the screen to be redrawn, xrefresh.

       Many  other  utilities,  window managers, games, toolkits,
       etc. are included as user-contributed software  in  the  X
       Consortium  distribution, or are available using anonymous
       ftp on the Internet.   See  your  site  administrator  for
       details.

STARTING UP
       There  are  two  main  ways of getting the X server and an
       initial set of client applications started.  The  particu-
       lar  method  used depends on what operating system you are
       running and whether or not you use other window systems in
       addition to X.

       xdm (the X Display Manager)
               If  you want to always have X running on your dis-
               play, your site administrator can set your machine
               up to use the X Display Manager xdm.  This program
               is typically started by the system  at  boot  time
               and  takes  care of keeping the server running and
               getting users logged in.  If you are running  xdm,
               you  will see a window on the screen welcoming you
               to the system and asking  for  your  username  and
               password.   Simply  type them in as you would at a
               normal terminal, pressing  the  Return  key  after
               each.   If you make a mistake, xdm will display an
               error message and ask you to try again.  After you
               have  successfully  logged  in,  xdm will start up
               your X environment.  By default, if  you  have  an
               executable  file  named  .xsession  in  your  home
               directory, xdm will treat  it  as  a  program  (or
               shell  script)  to  run  to  start up your initial
               clients (such as  terminal  emulators,  clocks,  a
               window  manager, user settings for things like the
               background, the speed of the pointer, etc.).  Your
               site administrator can provide details.

       xinit (run manually from the shell)
               Sites  that  support  more  than one window system
               might choose to use the xinit program for starting
               X  manually.   If  this  is true for your machine,
               your site administrator will  probably  have  pro-
               vided a program named "x11", "startx", or "xstart"
               that will do site-specific initialization (such as
               loading  convenient  default  resources, running a
               window manager, displaying a clock,  and  starting
               several  terminal  emulators)  in  a nice way.  If
               not, you can build such a script using  the  xinit
               program.  This utility simply runs one user-speci-
               fied program to start the server, runs another  to
               start  up  any desired clients, and then waits for
               either to finish.  Since either  or  both  of  the
               user-specified  programs  may  be  a shell script,
               this gives substantial flexibility at the  expense
               of  a  nice  interface.  For this reason, xinit is
               not intended for end users.

DISPLAY NAMES
       From the user's perspective, every X server has a  display
       name of the form:

                  hostname:displaynumber.screennumber

       This  information  is used by the application to determine
       how it should connect to the server and  which  screen  it
       should  use  by  default  (on displays with multiple moni-
       tors):

       hostname
               The hostname specifies the name of the machine  to
               which the display is physically connected.  If the
               hostname is not given, the most efficient  way  of
               communicating to a server on the same machine will
               be used.

       displaynumber
               The phrase "display" is usually used to  refer  to
               collection  of  monitors  that share a common key-
               board and pointer  (mouse,  tablet,  etc.).   Most
               workstations  tend  to only have one keyboard, and
               therefore, only one display.   Larger,  multi-user
               systems, however, frequently have several displays
               so that more than one person can be doing graphics
               work at once.  To avoid confusion, each display on
               a machine is assigned a display number  (beginning
               at  0)  when  the  X  server  for  that display is
               started.  The display number must always be  given
               in a display name.

       screennumber
               Some  displays share a single keyboard and pointer
               among two or more monitors.   Since  each  monitor
               has  its  own  set  of  windows,  each  screen  is
               assigned a screen number (beginning at 0) when the
               X  server  for  that  display  is started.  If the
               screen number is not given, screen 0 will be used.

       On  POSIX  systems,  the default display name is stored in
       your DISPLAY environment variable.  This variable  is  set
       automatically  by  the  xterm terminal emulator.  However,
       when you log into another machine on a network,  you  will
       need to set DISPLAY by hand to point to your display.  For
       example,

           % setenv DISPLAY myws:0
           $ DISPLAY=myws:0; export DISPLAY
       The xon script can be used to start  an  X  program  on  a
       remote machine; it automatically sets the DISPLAY variable
       correctly.

       Finally, most X programs accept a command line  option  of
       -display  displayname to temporarily override the contents
       of DISPLAY.  This is most commonly used to pop windows  on
       another  person's  screen  or  as part of a "remote shell"
       command to start an xterm pointing back to  your  display.
       For example,

           % xeyes -display joesws:0 -geometry 1000x1000+0+0
           % rsh big xterm -display myws:0 -ls </dev/null &

       X servers listen for connections on a variety of different
       communications channels (network byte streams, shared mem-
       ory,  etc.).  Since there can be more than one way of con-
       tacting a given server, The hostname part of  the  display
       name is used to determine the type of channel (also called
       a transport layer) to be used.  X servers  generally  sup-
       port the following types of connections:

       local
               The  hostname  part  of the display name should be
               the empty string.  For example:  :0, :1, and :0.1.
               The most efficient local transport will be chosen.

       TCPIP
               The hostname part of the display  name  should  be
               the server machine's IP address name.  Full Inter-
               net names, abbreviated names, and IP addresses are
               all   allowed.   For  example:   x.org:0,  expo:0,
               198.112.45.11:0, bigmachine:1, and hydra:0.1.

       DECnet
               The hostname part of the display  name  should  be
               the  server  machine's  nodename,  followed by two
               colons instead of  one.   For  example:   myws::0,
               big::1, and hydra::0.1.

ACCESS CONTROL
       An  X  server  can  use  several  types of access control.
       Mechanisms provided in Release 6 are:
           Host Access                   Simple host-based access control.
           MIT-MAGIC-COOKIE-1            Shared plain-text "cookies".
           XDM-AUTHORIZATION-1           Secure DES based private-keys.
           SUN-DES-1                     Based on Sun's secure rpc system.
           MIT-KERBEROS-5                Kerberos Version 5 user-to-user.

       Xdm initializes access control for  the  server  and  also
       places  authorization  information in a file accessible to
       the user.  Normally, the list of hosts from which  connec-
       tions  are  always  accepted should be empty, so that only
       clients with are explicitly authorized can connect to  the
       display.   When  you  add  entries  to the host list (with
       xhost), the server no longer performs any authorization on
       connections from those machines.  Be careful with this.

       The  file  from which Xlib extracts authorization data can
       be specified with the environment variable XAUTHORITY, and
       defaults  to  the  file .Xauthority in the home directory.
       Xdm uses $HOME/.Xauthority and will create it or merge  in
       authorization  records  if  it  already exists when a user
       logs in.

       If you use several machines and share a common home direc-
       tory across all of the machines by means of a network file
       system, you never really have to worry about authorization
       files,  the system should work correctly by default.  Oth-
       erwise, as the authorization  files  are  machine-indepen-
       dent,  you  can  simply  copy the files to share them.  To
       manage  authorization  files,  use  xauth.   This  program
       allows  you  to extract records and insert them into other
       files.  Using this, you can send authorization  to  remote
       machines  when  you  login, if the remote machine does not
       share a common home directory  with  your  local  machine.
       Note  that  authorization information transmitted ``in the
       clear'' through a network file system or using ftp or  rcp
       can  be  ``stolen'' by a network eavesdropper, and as such
       may enable unauthorized  access.   In  many  environments,
       this level of security is not a concern, but if it is, you
       need to know the exact semantics of the particular  autho-
       rization data to know if this is actually a problem.
       
	For  more information on access control, see the Xsecurity
       manual page.

GEOMETRY SPECIFICATIONS
       One of the advantages of using window systems  instead  of
       hardwired  terminals is that applications don't have to be
       restricted to a particular size or location on the screen.
       Although  the layout of windows on a display is controlled
       by the window manager that the user is running  (described
       below),  most X programs accept a command line argument of
       the form -geometry  WIDTHxHEIGHT+XOFF+YOFF  (where  WIDTH,
       HEIGHT,  XOFF, and YOFF are numbers) for specifying a pre-
       ferred size and location for this application's main  win-
       dow.

       The  WIDTH  and HEIGHT parts of the geometry specification
       are usually  measured  in  either  pixels  or  characters,
       depending on the application.  The XOFF and YOFF parts are
       measured in pixels and are used to specify the distance of
       the window from the left or right and top and bottom edges
       of the screen, respectively.  Both types  of  offsets  are
       measured from the indicated edge of the screen to the cor-
       responding edge of the window.  The X offset may be speci-
       fied in the following ways:

       +XOFF   The  left  edge of the window is to be placed XOFF
               pixels in from the left edge of the screen  (i.e.,
               the  X  coordinate  of the window's origin will be
               XOFF).  XOFF may be negative, in  which  case  the
               window's left edge will be off the screen.

       -XOFF   The  right edge of the window is to be placed XOFF
               pixels in from the right edge of the screen.  XOFF
               may  be negative, in which case the window's right
               edge will be off the screen.

       The Y offset has similar meanings:

       +YOFF   The top edge of the window is to  be  YOFF  pixels
               below  the  top  edge  of  the screen (i.e., the Y
               coordinate of the window's origin will  be  YOFF).
               YOFF  may  be negative, in which case the window's
               top edge will be off the screen.

       -YOFF   The bottom edge of the window is to be YOFF pixels
               above  the bottom edge of the screen.  YOFF may be
               negative, in which case the window's  bottom  edge
               will be off the screen.

       Offsets  must  be given as pairs; in other words, in order
       to specify either XOFF or YOFF both must be present.  Win-
       dows can be placed in the four corners of the screen using
       the following specifications:

       +0+0    upper left hand corner.

       -0+0    upper right hand corner.

       -0-0    lower right hand corner.

       +0-0    lower left hand corner.

       In the following examples, a terminal emulator  is  placed
       in  roughly  the  center  of the screen and a load average
       monitor, mailbox, and clock are placed in the upper  right
       hand corner:

           xterm -fn 6x10 -geometry 80x24+30+200 &
           xclock -geometry 48x48-0+0 &
           xload -geometry 48x48-96+0 &
           xbiff -geometry 48x48-48+0 &

WINDOW MANAGERS
       The  layout of windows on the screen is controlled by spe-
       cial programs called window managers.  Although many  win-
       dow  managers will honor geometry specifications as given,
       others may choose to ignore them (requiring  the  user  to
       explicitly draw the window's region on the screen with the
       pointer, for example).

       Since window managers are regular (albeit complex)  client
       programs,  a  variety  of different user interfaces can be
       built.  The X Consortium distribution comes with a  window
       manager  named  twm  which  supports  overlapping windows,
       popup menus, point-and-click or click-to-type  input  mod-
       els, title bars, nice icons (and an icon manager for those
       who don't like separate icon windows).

       See the user-contributed software in the X Consortium dis-
       tribution for other popular window managers.

FONT NAMES
       Collections  of characters for displaying text and symbols
       in X are known as fonts.  A font typically contains images
       that share a common appearance and look nice together (for
       example, a single size,  boldness,  slant,  and  character
       set).  Similarly, collections of fonts that are based on a
       common type face (the variations are usually called roman,
       bold,  italic, bold italic, oblique, and bold oblique) are
       called families.

       Fonts come in various sizes.  The X server supports  scal-
       able  fonts,  meaning  it  is possible to create a font of
       arbitrary size from a single source  for  the  font.   The
       server  supports  scaling  from  outline  fonts and bitmap
       fonts.  Scaling from outline fonts usually  produces  sig-
       nificantly  better results than scaling from bitmap fonts.

       An X server can obtain fonts from individual files  stored
       in  directories  in  the  file system, or from one or more
       font servers, or from a mixtures of directories  and  font
       servers.   The list of places the server looks when trying
       to find a font is controlled by its font  path.   Although
       most installations will choose to have the server start up
       with all of the commonly used font directories in the font
       path,  the  font  path can be changed at any time with the
       xset program.  However, it is important to  remember  that
       the  directory  names  are on the server's machine, not on
       the application's.

       Bitmap font files are usually created by compiling a  tex-
       tual  font  description  into binary form, using bdftopcf.
       Font databases are created by running the  mkfontdir  pro-
       gram  in  the  directory containing the source or compiled
       versions of the fonts.  Whenever  fonts  are  added  to  a
       directory,  mkfontdir  should  be rerun so that the server
       can find the new fonts.  To make  the  server  reread  the
       font  database, reset the font path with the xset program.
       For example, to add a font to  a  private  directory,  the
       following commands could be used:

           % cp newfont.pcf ~/myfonts
           % mkfontdir ~/myfonts
           % xset fp rehash

       The  xfontsel  and xlsfonts programs can be used to browse
       through the fonts available on a server.  Font names  tend
       to  be  fairly long as they contain all of the information
       needed to uniquely identify  individual  fonts.   However,
       the  X  server  supports wildcarding of font names, so the
       full specification

           -adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1

       might be abbreviated as:

           -*-courier-medium-r-normal--*-100-*-*-*-*-iso8859-1

       Because the shell also has special meanings for *  and  ?,
       wildcarded font names should be quoted:

           % xlsfonts -fn '-*-courier-medium-r-normal--*-100-*-*-*-*-*-*'

       The  xlsfonts program can be used to list all of the fonts
       that match a given pattern.  With no arguments,  it  lists
       all available fonts.  This will usually list the same font
       at many different sizes.  To see just  the  base  scalable
       font names, try using one of the following patterns:

           -*-*-*-*-*-*-0-0-0-0-*-0-*-*
           -*-*-*-*-*-*-0-0-75-75-*-0-*-*
           -*-*-*-*-*-*-0-0-100-100-*-0-*-*

       To  convert  one  of  the resulting names into a font at a
       specific size, replace one of the first two zeros  with  a
       nonzero value.  The field containing the first zero is for
       the pixel size; replace it with a specific height in  pix-
       els to name a font at that size.  Alternatively, the field
       containing the second zero is for the point size;  replace
       it  with  a  specific  size in decipoints (there are 722.7
       decipoints to the inch) to name a font at that size.   The
       last zero is an average width field, measured in tenths of
       pixels; some servers will  anamorphically  scale  if  this
       value is specified.

FONT SERVER NAMES
       One  of  the  following  forms  can be used to name a font
       server that accepts TCP connections:

           tcp/hostname:port
           tcp/hostname:port/cataloguelist

       The  hostname  specifies  the  name  (or  decimal  numeric
       address)  of  the machine on which the font server is run-
       ning.  The port is the decimal TCP port on which the  font
       server  is  listening  for connections.  The cataloguelist
       specifies a list of catalogue names, with '+' as a separa-
       tor.

       Examples: tcp/x.org:7100, tcp/198.112.45.11:7100/all.

       One  of  the  following  forms  can be used to name a font
       server that accepts DECnet connections:

           decnet/nodename::font$objname
           decnet/nodename::font$objname/cataloguelist

       The  nodename  specifies  the  name  (or  decimal  numeric
       address)  of  the machine on which the font server is run-
       ning.  The objname is a  normal,  case-insensitive  DECnet
       object  name.  The cataloguelist specifies a list of cata-
       logue names, with '+' as a separator.

       Examples:        DECnet/SRVNOD::FONT$DEFAULT,         dec-
       net/44.70::font$special/symbols.

COLOR NAMES
       Most  applications  provide  ways  of  tailoring  (usually
       through resources or command line arguments) the colors of
       various elements in the text and graphics they display.  A
       color can be specified either by an abstract  color  name,
       or  by  a  numerical  color  specification.  The numerical
       specification can identify a color in either device-depen-
       dent (RGB) or device-independent terms.  Color strings are
       case-insensitive.

       X supports the use of abstract color names,  for  example,
       "red", "blue".  A value for this abstract name is obtained
       by searching one or more color name databases.  Xlib first
       searches  zero  or more client-side databases; the number,
       location, and content of these databases is implementation
       dependent.   If the name is not found, the color is looked
       up in the X server's database.   The  text  form  of  this
       database     is    commonly    stored    in    the    file
       <XRoot>/lib/X11/rgb.txt, where <XRoot> is replaced by  the
       root of the X11 install tree.

       A  numerical color specification consists of a color space
       name and a set of values in the following syntax:

           <color_space_name>:<value>/.../<value>

       An RGB Device specification is identified  by  the  prefix
       "rgb:" and has the following syntax:

           rgb:<red>/<green>/<blue>

               <red>, <green>, <blue> := h | hh | hhh | hhhh
               h := single hexadecimal digits
       Note  that  h indicates the value scaled in 4 bits, hh the
       value scaled in 8 bits, hhh the value scaled in  12  bits,
       and hhhh the value scaled in 16 bits, respectively.  These
       values are passed  directly  to  the  X  server,  and  are
       assumed to be gamma corrected.

       The eight primary colors can be represented as:

           black                rgb:0/0/0
           red                  rgb:ffff/0/0
           green                rgb:0/ffff/0
           blue                 rgb:0/0/ffff
           yellow               rgb:ffff/ffff/0
           magenta              rgb:ffff/0/ffff
           cyan                 rgb:0/ffff/ffff
           white                rgb:ffff/ffff/ffff

       For backward compatibility, an older syntax for RGB Device
       is supported, but its continued  use  is  not  encouraged.
       The  syntax is an initial sharp sign character followed by
       a numeric specification, in one of the following formats:

           #RGB                      (4 bits each)
           #RRGGBB                   (8 bits each)
           #RRRGGGBBB                (12 bits each)
           #RRRRGGGGBBBB             (16 bits each)

       The R, G, and B represent single hexadecimal digits.  When
       fewer  than 16 bits each are specified, they represent the
       most-significant bits of the value (unlike the "rgb:" syn-
       tax,  in  which  values are scaled).  For example, #3a7 is
       the same as #3000a0007000.

       An RGB intensity specification is identified by the prefix
       "rgbi:" and has the following syntax:

           rgbi:<red>/<green>/<blue>

       The red, green, and blue are floating point values between
       0.0 and 1.0, inclusive.  They represent  linear  intensity
       values,  with  1.0  indicating  full  intensity,  0.5 half
       intensity, and so on.  These values  will  be  gamma  cor-
       rected  by  Xlib  before  being sent to the X server.  The
       input format for these  values  is  an  optional  sign,  a
       string of numbers possibly containing a decimal point, and
       an optional exponent field containing an E or  e  followed
       by a possibly signed integer string.

       The standard device-independent string specifications have
       the following syntax:

           CIEXYZ:<X>/<Y>/<Z>             (none, 1, none)
           CIEuvY:<u>/<v>/<Y>             (~.6, ~.6, 1)
           CIExyY:<x>/<y>/<Y>             (~.75, ~.85, 1)
           CIELab:<L>/<a>/<b>             (100, none, none)
           CIELuv:<L>/<u>/<v>             (100, none, none)
           TekHVC:<H>/<V>/<C>             (360, 100, 100)

       All of the values (C, H, V, X, Y, Z, a, b, u, v, y, x) are
       floating point values.  Some of the values are constrained
       to be between zero and some upper bound; the upper  bounds
       are given in parentheses above.  The syntax for these val-
       ues is an optional '+' or '-' sign,  a  string  of  digits
       possibly containing a decimal point, and an optional expo-
       nent field consisting of an 'E'  or  'e'  followed  by  an
       optional '+' or '-' followed by a string of digits.

       For  more information on device independent color, see the
       Xlib reference manual.

KEYBOARDS
       The X keyboard model is broken into two  layers:   server-
       specific codes (called keycodes) which represent the phys-
       ical keys, and server-independent symbols (called keysyms)
       which  represent  the  letters or words that appear on the
       keys.  Two tables are kept in the  server  for  converting
       keycodes to keysyms:

       modifier list
               Some  keys (such as Shift, Control, and Caps Lock)
               are known as modifier and are used to select  dif-
               ferent  symbols  that are attached to a single key
               (such as Shift-a generates a capital A,  and  Con-
               trol-l  generates  a  control  character ^L).  The
               server keeps a list of keycodes  corresponding  to
               the  various  modifier  keys.   Whenever  a key is
               pressed or released, the server generates an event
               that  contains the keycode of the indicated key as
               well as a mask that specifies which of  the  modi-
               fier keys are currently pressed.  Most servers set
               up this list  to  initially  contain  the  various
               shift,  control,  and  shift lock keys on the key-
               board.

       keymap table
               Applications translate event keycodes and modifier
               masks into keysyms using a keysym table which con-
               tains one row for each keycode and one column  for
               various  modifier  states.  This table is initial-
               ized by the server to correspond to  normal  type-
               writer  conventions.   The  exact semantics of how
               the  table  is  interpreted  to  produce   keysyms
               depends  on the particular program, libraries, and
               language input method used, but the following con-
               ventions  for  the  first four keysyms in each row
               are generally adhered to:

       The first four elements of the list  are  split  into  two
       groups  of keysyms.  Group 1 contains the first and second
       keysyms; Group 2 contains the third  and  fourth  keysyms.
       Within  each group, if the first element is alphabetic and
       the the second element is  the  special  keysym  NoSymbol,
       then  the  group  is  treated  as equivalent to a group in
       which the first element is the lowercase  letter  and  the
       second element is the uppercase letter.

       Switching between groups is controlled by the keysym named
       MODE SWITCH, by attaching that  keysym  to  some  key  and
       attaching  that  key  to  any  one  of  the modifiers Mod1
       through Mod5.  This modifier is called the  ``group  modi-
       fier.''   Group  1 is used when the group modifier is off,
       and Group 2 is used when the group modifier is on.

       Within a group, the modifier state determines which keysym
       to  use.  The first keysym is used when the Shift and Lock
       modifiers are off.  The second keysym  is  used  when  the
       Shift modifier is on, when the Lock modifier is on and the
       second keysym is uppercase alphabetic, or  when  the  Lock
       modifier  is  on  and is interpreted as ShiftLock.  Other-
       wise, when the Lock modifier is on and is  interpreted  as
       CapsLock, the state of the Shift modifier is applied first
       to select a keysym; but if that keysym is lowercase alpha-
       betic,  then  the  corresponding  uppercase keysym is used
       instead.

OPTIONS
       Most X programs attempt to use the same names for  command
       line options and arguments.  All applications written with
       the X Toolkit Intrinsics automatically accept the  follow-
       ing options:

       -display display
               This  option specifies the name of the X server to

               use.

       -geometry geometry
               This option specifies the initial size  and  loca-
               tion of the window.

       -bg color, -background color
               Either  option  specifies the color to use for the
               window background.

       -bd color, -bordercolor color
               Either option specifies the color to use  for  the
               window border.

       -bw number, -borderwidth number
               Either option specifies the width in pixels of the
               window border.

       -fg color, -foreground color
               Either option specifies the color to use for  text
               or graphics.

       -fn font, -font font
               Either  option  specifies the font to use for dis-
               playing text.

       -iconic
               This option indicates that the user  would  prefer
               that  the  application's  windows initially not be
               visible as  if  the  windows  had  be  immediately
               iconified by the user.  Window managers may choose
               not to honor the application's request.

       -name
               This  option  specifies  the  name   under   which
               resources  for  the  application  should be found.
               This option is useful in shell aliases to  distin-
               guish between invocations of an application, with-
               out resorting to creating links to alter the  exe-
               cutable file name.

       -rv, -reverse
               Either  option  indicates  that the program should
               simulate reverse video if possible, often by swap-
               ping  the  foreground  and background colors.  Not
               all programs honor this or implement it correctly.
               It is usually only used on monochrome displays.

       +rv
               This  option indicates that the program should not
               simulate reverse video.  This is used to  override
               any  defaults  since  reverse video doesn't always
               work properly.

       -selectionTimeout
               This option specifies the timeout in  milliseconds
               within  which  two communicating applications must
               respond to one another for a selection request.

       -synchronous
               This option  indicates  that  requests  to  the  X
               server  should  be  sent synchronously, instead of
               asynchronously.   Since  Xlib   normally   buffers
               requests  to the server, errors do not necessarily
               get reported immediately after they  occur.   This
               option  turns off the buffering so that the appli-
               cation can be debugged.  It should never  be  used
               with a working program.

       -title string
               This  option  specifies  the  title to be used for
               this window.  This information is  sometimes  used
               by a window manager to provide some sort of header
               identifying the window.

       -xnllanguage language[_territory][.codeset]
               This option specifies the language, territory, and
               codeset  for  use  in resolving resource and other
               filenames.

       -xrm resourcestring
               This option specifies a resource name and value to
               override any defaults.  It is also very useful for
               setting resources that don't have explicit command
               line arguments.

RESOURCES
       To  make the tailoring of applications to personal prefer-
       ences easier, X provides a mechanism for  storing  default
       values  for program resources (e.g. background color, win-
       dow title, etc.)  Resources are specified as strings  that
       are  read  in  from  various places when an application is
       run.  Program components are named in a hierarchical fash-
       ion, with each node in the hierarchy identified by a class
       and an instance name.  At the top level is the  class  and
       instance  name  of the application itself.  By convention,
       the class name of the application is the same as the  pro-
       gram  name,  but  with  the first letter capitalized (e.g.
       Bitmap or Emacs) although some programs  that  begin  with
       the  letter  ``x''  also  capitalize the second letter for
       historical reasons.

       The precise syntax for resources is:

       ResourceLine      = Comment | IncludeFile | ResourceSpec | <empty line>
       Comment           = "!" {<any character except null or newline>}
       IncludeFile       = "#" WhiteSpace "include" WhiteSpace FileName WhiteSpace
       FileName          = <valid filename for operating system>
       ResourceSpec      = WhiteSpace ResourceName WhiteSpace ":" WhiteSpace Value
       ResourceName      = [Binding] {Component Binding} ComponentName
       Binding           = "." | "*"
       WhiteSpace        = {<space> | <horizontal tab>}
       Component         = "?" | ComponentName
       ComponentName     = NameChar {NameChar}
       NameChar          = "a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-"
       Value             = {<any character except null or unescaped newline>}

       Elements separated by vertical bar (|)  are  alternatives.
       Curly  braces ({...}) indicate zero or more repetitions of
       the enclosed elements.  Square brackets  ([...])  indicate
       that the enclosed element is optional.  Quotes ("...") are
       used around literal characters.

       IncludeFile lines are interpreted by  replacing  the  line
       with  the  contents  of  the  specified  file.   The  word
       "include" must be in lowercase.  The  filename  is  inter-
       preted  relative to the directory of the file in which the
       line occurs (for example,  if  the  filename  contains  no
       directory or contains a relative directory specification).

       If a ResourceName contains a contiguous sequence of two or
       more  Binding  characters,  the  sequence will be replaced
       with single "." character if the  sequence  contains  only
       "."  characters,  otherwise  the sequence will be replaced
       with a single "*" character.

       A resource database never contains more than one entry for
       a  given ResourceName.  If a resource file contains multi-
       ple lines with the same ResourceName, the last line in the
       file is used.

       Any whitespace character before or after the name or colon
       in a ResourceSpec are ignored.  To allow a Value to  begin
       with  whitespace,  the  two-character  sequence ``\space''
       (backslash followed by space) is recognized  and  replaced
       by  a  space  character,  and  the  two-character sequence
       ``\tab'' (backslash followed by horizontal tab) is  recog-
       nized  and  replaced  by  a  horizontal tab character.  To
       allow a Value to contain embedded newline characters,  the
       two-character  sequence  ``\n'' is recognized and replaced
       by a newline character.  To allow a  Value  to  be  broken
       across  multiple  lines  in a text file, the two-character
       sequence ``\newline'' (backslash followed by  newline)  is
       recognized  and  removed from the value.  To allow a Value
       to contain arbitrary character codes,  the  four-character
       sequence  ``\nnn'',  where  each n is a digit character in
       the range of ``0''-``7'', is recognized and replaced  with
       a  single  byte that contains the octal value specified by
       the sequence.  Finally, the two-character sequence  ``\\''
       is recognized and replaced with a single backslash.

       When  an application looks for the value of a resource, it
       specifies a complete path  in  the  hierarchy,  with  both
       class  and  instance  names.  However, resource values are
       usually given with  only  partially  specified  names  and
       classes,  using  pattern matching constructs.  An asterisk
       (*) is a loose binding and is used to represent any number
       of  intervening  components, including none.  A period (.)
       is a tight binding and is  used  to  separate  immediately
       adjacent components.  A question mark (?) is used to match
       any single component name or class.  A database entry can-
       not  end  in  a  loose binding; the final component (which
       cannot be "?") must be specified.   The  lookup  algorithm
       searches  the  resource  database  for the entry that most
       closely matches (is most specific for) the full  name  and
       class  being  queried.   When more than one database entry
       matches the full name and class, precedence rules are used
       to select just one.

       The  full  name  and  class are scanned from left to right
       (from highest level in the hierarchy to lowest), one  com-
       ponent at a time.  At each level, the corresponding compo-
       nent and/or binding of each matching entry is  determined,
       and  these  matching  components and bindings are compared
       according to precedence  rules.   Each  of  the  rules  is
       applied  at  each  level, before moving to the next level,
       until a rule selects a single entry over all others.   The
       rules (in order of precedence) are:

       1.   An  entry that contains a matching component (whether
            name, class, or "?")  takes precedence  over  entries
            that elide the level (that is, entries that match the
            level in a loose binding).

       2.   An entry with a matching name takes  precedence  over
            both  entries  with a matching class and entries that
            match using "?".  An  entry  with  a  matching  class
            takes precedence over entries that match using "?".

       3.   An entry preceded by a tight binding takes precedence
            over entries preceded by a loose binding.

       Programs based on the X Tookit Intrinsics obtain resources
       from the following sources (other programs usually support
       some subset of these sources):

       RESOURCE_MANAGER root window property
               Any global resources that should be  available  to
               clients  on  all  machines should be stored in the
               RESOURCE_MANAGER property on the  root  window  of
               the  first screen using the xrdb program.  This is
               frequently taken care of when the user starts up X
               through the display manager or xinit.

       SCREEN_RESOURCES root window property
               Any  resources  specific  to  a given screen (e.g.
               colors) that should be available to clients on all
               machines  should be stored in the SCREEN_RESOURCES
               property on the root window of that  screen.   The
               xrdb program will sort resources automatically and
               place     them     in     RESOURCE_MANAGER      or
               SCREEN_RESOURCES, as appropriate.

       application-specific files
               Directories  named  by  the  environment  variable
               XUSERFILESEARCHPATH or  the  environment  variable
               XAPPLRESDIR  (which  names  a single directory and
               should end with a  '/'  on  POSIX  systems),  plus
               directories  in  a  standard  place (usually under
               <XRoot>/lib/X11/, but this can be overridden  with
               the   XFILESEARCHPATH  environment  variable)  are
               searched for for  application-specific  resources.
               For  example,  application  default  resources are
               usually  kept  in   <XRoot>/lib/X11/app-defaults/.
               See  the  X Toolkit Intrinsics - C Language Inter-
               face manual for details.


       XENVIRONMENT
               Any user- and machine-specific  resources  may  be
               specified  by setting the XENVIRONMENT environment
               variable to the name of  a  resource  file  to  be
               loaded  by  all applications.  If this variable is
               not defined, a file  named  $HOME/.Xdefaults-host-
               name  is looked for instead, where hostname is the
               name of the host where the application is  execut-
               ing.

       -xrm resourcestring
               Resources  can  also be specified from the command
               line.  The resourcestring  is  a  single  resource
               name  and  value as shown above.  Note that if the
               string  contains  characters  interpreted  by  the
               shell  (e.g., asterisk), they must be quoted.  Any
               number of -xrm arguments may be given on the  com-
               mand line.

       Program   resources   are  organized  into  groups  called
       classes, so that collections of individual resources (each
       of which are called instances) can be set all at once.  By
       convention, the instance name of a resource begins with  a
       lowercase letter and class name with an upper case letter.
       Multiple word resources are concatenated  with  the  first
       letter  of the succeeding words capitalized.  Applications
       written with the X Toolkit Intrinsics will have  at  least
       the following resources:

       background (class Background)
               This  resource  specifies the color to use for the
               window background.

       borderWidth (class BorderWidth)
               This resource specifies the width in pixels of the
               window border.

       borderColor (class BorderColor)
               This  resource  specifies the color to use for the
               window border.

       Most applications using the X Toolkit Intrinsics also have
       the resource foreground (class Foreground), specifying the
       color to use for text and graphics within the window.

       By combining class and instance  specifications,  applica-
       tion  preferences can be set quickly and easily.  Users of
       color displays will frequently want to set Background  and
       Foreground classes to particular defaults.  Specific color
       instances such as text  cursors  can  then  be  overridden
       without  having  to  define  all of the related resources.
       For example,

           bitmap*Dashed:  off
           XTerm*cursorColor:  gold
           XTerm*multiScroll:  on
           XTerm*jumpScroll:  on
           XTerm*reverseWrap:  on
           XTerm*curses:  on
           XTerm*Font:  6x10
           XTerm*scrollBar: on
           XTerm*scrollbar*thickness: 5
           XTerm*multiClickTime: 500
           XTerm*charClass:  33:48,37:48,45-47:48,64:48
           XTerm*cutNewline: off
           XTerm*cutToBeginningOfLine: off
           XTerm*titeInhibit:  on


           XTerm*ttyModes:  intr ^c erase ^? kill ^u
           XLoad*Background: gold
           XLoad*Foreground: red
           XLoad*highlight: black
           XLoad*borderWidth: 0
           emacs*Geometry:  80x65-0-0
           emacs*Background:  rgb:5b/76/86
           emacs*Foreground:  white
           emacs*Cursor:  white
           emacs*BorderColor:  white
           emacs*Font:  6x10
           xmag*geometry: -0-0
           xmag*borderColor:  white

       If these resources were stored  in  a  file  called  .Xre-
       sources in your home directory, they could be added to any
       existing resources in the server with the  following  com-
       mand:

           % xrdb -merge $HOME/.Xresources

       This is frequently how user-friendly startup scripts merge
       user-specific defaults into any site-wide  defaults.   All
       sites are encouraged to set up convenient ways of automat-
       ically loading resources.  See  the  Xlib  manual  section
       Resource Manager Functions for more information.

EXAMPLES
       The  following is a collection of sample command lines for
       some of the  more  frequently  used  commands.   For  more
       information  on a particular command, please refer to that
       command's manual page.

           %  xrdb $HOME/.Xresources
           %  xmodmap -e "keysym BackSpace = Delete"
           %  mkfontdir /usr/local/lib/X11/otherfonts
           %  xset fp+ /usr/local/lib/X11/otherfonts
           %  xmodmap $HOME/.keymap.km
           %  xsetroot -solid 'rgbi:.8/.8/.8'
           %  xset b 100 400 c 50 s 1800 r on
           %  xset q
           %  twm
           %  xmag
           %  xclock -geometry 48x48-0+0 -bg blue -fg white
           %  xeyes -geometry 48x48-48+0
           %  xbiff -update 20
           %  xlsfonts '*helvetica*'
           %  xwininfo -root
           %  xdpyinfo -display joesworkstation:0
           %  xhost -joesworkstation
           %  xrefresh
           %  xwd | xwud
           %  bitmap companylogo.bm 32x32
           %  xcalc -bg blue -fg magenta
           %  xterm -geometry 80x66-0-0 -name myxterm $*
           %  xon filesysmachine xload

DIAGNOSTICS
       A wide variety of error messages are generated from  vari-
       ous  programs.   The  default  error handler in Xlib (also
       used by many toolkits) uses  standard  resources  to  con-
       struct   diagnostic   messages  when  errors  occur.   The
       defaults  for  these  messages  are  usually   stored   in
       <XRoot>/lib/X11/XErrorDB.   If  this  file is not present,
       error messages will be rather terse and cryptic.

       When the X Toolkit Intrinsics encounter errors  converting
       resource  strings  to  the appropriate internal format, no

       error messages are usually printed.   This  is  convenient
       when it is desirable to have one set of resources across a
       variety of displays (e.g. color vs.  monochrome,  lots  of
       fonts  vs.  very few, etc.), although it can pose problems
       for trying to determine why an application might be  fail-
       ing.   This  behavior can be overridden by the setting the
       StringConversionsWarning resource.

       To force the X Toolkit Intrinsics to always  print  string
       conversion  error  messages, the following resource should
       be  placed  in  the  file  that  gets  loaded   onto   the
       RESOURCE_MANAGER  property  using  the  xrdb program (fre-
       quently called .Xresources or .Xres  in  the  user's  home
       directory):

           *StringConversionWarnings: on

       To  have conversion messages printed for just a particular
       application, the appropriate instance name can  be  placed
       before the asterisk:

           xterm*StringConversionWarnings: on

SEE ALSO
       XConsortium(1), XStandards(1), Xsecurity(1),

       appres(1),  bdftopcf(1), bitmap(1), editres(1), fsinfo(1),
       fslsfonts(1),  fstobdf(1),  iceauth(1),   imake(1),   lbx-
       proxy(1),  makedepend(1), mkfontdir(1), oclock(1), proxym-
       ngr(1), rgb(1), resize(1), rstart(1), smproxy(1),  twm(1),
       x11perf(1),   x11perfcomp(1),   xauth(1),   xclipboard(1),
       xclock(1), xcmsdb(1),  xconsole(1),  xdm(1),  xdpyinfo(1),
       xfd(1),    xfindproxy(1),   xfs(1),   xfwp(1),   xhost(1),
       xieperf(1), xinit(1), xkbbell(1),  xkbcomp(1),  xbkevd(1),
       xkbprint(1), xkbvleds(1), xkbwatch(1), xkill(1), xlogo(1),
       xlsatoms(1), xlsclients(1), xlsfonts(1), xmag(1),  xmh(1),
       xmodmap(1),   xon(1),   xprop(1),   xrdb(1),  xrefresh(1),
       xrx(1),   xset(1),   xsetroot(1),   xsm(1),   xstdcmap(1),
       xterm(1),   xwd(1),   xwininfo(1),  xwud(1).   Xserver(1),
       Xdec(1),   XmacII(1),    Xsun(1),    Xnest(1),    Xvfb(1),
       XF86_Acc(1),  XF86_Mono(1),  XF86_SVGA(1),  XF86_VGA16(1),
       XFree86(1), kbd_mode(1), Xlib - C  Language  X  Interface,
       and X Toolkit Intrinsics - C Language Interface

TRADEMARKS
       X Window System is a trademark of X Consortium, Inc.

AUTHORS
       A cast of thousands, literally.  The Release 6.3 distribu-
       tion is brought to you by X Consortium, Inc.  The names of
       all  people  who  made  it  a reality will be found in the
       individual documents and source files.  The staff  members
       at  the  X  Consortium  responsible  for this release are:
       Donna  Converse  (emeritus),  Stephen  Gildea  (emeritus),
       Kaleb  Keithley, Matt Landau (emeritus), Ralph Mor (emeri-
       tus), Janet O'Halloran, Bob Scheifler, Ralph  Swick,  Dave
       Wiggins (emeritus), and Reed Augliere.

       The  X  Window System standard was originally developed at
       the Laboratory for Computer Science at  the  Massachusetts
       Institute  of  Technology,  and  all  rights  thereto were
       assigned to the X Consortium on January 1, 1994.   X  Con-
       sortium,  Inc. closed its doors on December 31, 1996.  All
       rights to the X Window System have been  assigned  to  the
       Open Software Foundation.

X Version 11               Release 6.3                          1

(END)

"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

XHOST(1)                                                 XHOST(1)

NAME
       xhost - server access control program for X

SYNOPSIS
       xhost [[+-]name ...]

DESCRIPTION
       The  xhost program is used to add and delete host names or
       user names to the list allowed to make connections to  the
       X  server.  In the case of hosts, this provides a rudimen-
       tary form of privacy control and  security.   It  is  only
       sufficient  for  a  workstation (single user) environment,
       although it does limit  the  worst  abuses.   Environments
       which require more sophisticated measures should implement
       the user-based mechanism or use the hooks in the  protocol
       for passing other authentication data to the server.

OPTIONS
       Xhost accepts the following command line options described
       below.  For security, the options that effect access  con-
       trol  may  only  be  run from the "controlling host".  For
       workstations, this is the same machine as the server.  For
       X terminals, it is the login host.

       -help   Prints a usage message.

       [+]name The  given  name  (the  plus  sign is optional) is
               added to the list allowed  to  connect  to  the  X
               server.   The  name  can  be a host name or a user
               name.

       -name   The given name is removed from the list of allowed
               to  connect to the server.  The name can be a host
               name or a user name.  Existing connections are not
               broken,   but  new  connection  attempts  will  be
               denied.  Note that the current machine is  allowed
               to   be   removed;  however,  further  connections
               (including attempts to add it back)  will  not  be
               permitted.  Resetting the server (thereby breaking
               all connections) is the only way  to  allow  local
               connections again.

       +       Access is granted to everyone, even if they aren't
               on the list (i.e., access control is turned  off).
       -       Access  is  restricted  to  only those on the list
               (i.e., access control is turned on).

       nothing If no command line arguments are given, a  message
               indicating  whether  or not access control is cur-
               rently enabled is printed, followed by the list of
               those allowed to connect.  This is the only option
               that may be used from machines other than the con-
               trolling host.

NAMES
       A  complete  name has the syntax ``family:name'' where the
       families are as follows:

       inet      Internet host
       dnet      DECnet host
       nis       Secure RPC network name
       krb       Kerberos V5 principal
       local     contains only one name, the empty string

       The family is case insensitive.  The format  of  the  name
       varies with the family.

       When  Secure  RPC  is  being used, the network independent
       netname (e.g., "nis:unix.uid@domainname")  can  be  speci-
       fied, or a local user can be specified with just the user-
       name and a trailing at-sign (e.g., "nis:pat@").

       For backward compatibility with pre-R6 xhost,  names  that
       contain  an  at-sign (@) are assumed to be in the nis fam-
       ily.  Otherwise the inet family is assumed.

DIAGNOSTICS
       For each name added to the access control list, a line  of
       the  form  "name  being  added  to access control list" is
       printed.  For each name removed from  the  access  control
       list,  a  line of the form "name being removed from access
       control list" is printed.

FILES
       /etc/X*.hosts

SEE ALSO
       X(1), Xsecurity(1), Xserver(1), xdm(1)

ENVIRONMENT
       DISPLAY to get the default host and display to use

BUGS
       You can't specify a display on the  command  line  because
       -display is a valid command line argument (indicating that
       you want to remove the machine named ``display'' from  the
       access list).

       The  X  server  stores  network addresses, not host names.
       This is not really a bug.  If somehow you change a  host's
       network  address  while the server is still running, xhost
       must be used to add the new address and/or remove the  old
       address.

AUTHORS
       Bob Scheifler, MIT Laboratory for Computer Science,
       Jim Gettys, MIT Project Athena (DEC).

X Version 11               Release 6.3                          1


"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

XWD(1)                                                     XWD(1)

NAME
       xwd - dump an image of an X window

SYNOPSIS
       xwd  [-debug] [-help] [-nobdrs] [-out file] [-xy] [-frame]
       [-add value] [-root | -id  id  |  -name  name  ]  [-icmap]
       [-screen] [-display display]

DESCRIPTION
       Xwd  is  an  X  Window System window dumping utility.  Xwd
       allows X users to store window images in a specially  for-
       matted  dump  file.  This file can then be read by various
       other X utilities for redisplay, printing,  editing,  for-
       matting,  archiving,  image  processing,  etc.  The target
       window is selected by clicking the pointer in the  desired
       window.   The  keyboard bell is rung once at the beginning
       of the dump and twice when the dump is completed.

OPTIONS
       -display display
               This argument allows you to specify the server  to
               connect to; see X(1).

       -help   Print out the `Usage:' command syntax summary.

       -nobdrs This  argument  specifies  that  the  window  dump
               should not include the pixels that compose  the  X
               window border.  This is useful in situations where
               you may wish to include the window contents  in  a
               document as an illustration.

       -out file
               This  argument allows the user to explicitly spec-
               ify the output file  on  the  command  line.   The
               default is to output to standard out.

       -xy     This  option  applies  to  color displays only. It
               selects `XY' format dumping instead of the default
               `Z' format.

       -add value
               This  option specifies an signed value to be added
               to every pixel.

       -frame  This option  indicates  that  the  window  manager
               frame should be included when manually selecting a
               window.

       -root   This option indicates that the root window  should
               be selected for the window dump, without requiring
               the user to select a window with the pointer.

       -id id  This option indicates that  the  window  with  the
               specified  resource  id should be selected for the
               window dump, without requiring the user to  select
               a window with the pointer.

       -name name
               This  option  indicates  that  the window with the
               specified WM_NAME property should be selected  for
               the  window  dump,  without  requiring the user to
               select a window with the pointer.

       -icmap  Normally the colormap of the chosen window is used
               to  obtain  RGB  values.   This  option forces the
               first installed colormap of the screen to be  used
               instead.

       -screen This  option  indicates  that the GetImage request
               used to obtain the image should  be  done  on  the
               root window, rather than directly on the specified
               window.  In this way, you  can  obtain  pieces  of
               other  windows  that overlap the specified window,
               and more importantly, you  can  capture  menus  or
               other  popups  that  are  independent  windows but
               appear over the specified window.

       -silent Operate silently, i.e. don't ring any bells before
               and after dumping the window.

ENVIRONMENT
       DISPLAY To get default host and display number.

FILES
       XWDFile.h
               X Window Dump File format definition file.

SEE ALSO
       xwud(1), xpr(1), X(1)

AUTHORS
       Tony  Della  Fera,  Digital  Equipment  Corp., MIT Project
       Athena
       William F. Wyatt, Smithsonian Astrophysical Observatory

X Version 11               Release 6.3                          1





""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""



XSERVER(1)                                             XSERVER(1)

NAME
       Xserver - X Window System display server

SYNOPSIS
       X [option ...]

DESCRIPTION
       X  is  the  generic  name  for the X Window System display
       server.  It is frequently a link or a copy of  the  appro-
       priate  server binary for driving the most frequently used
       server on a given machine.

STARTING THE SERVER
       The X server is usually started from the X Display Manager
       program  xdm(1).  This utility is run from the system boot
       files and  takes  care  of  keeping  the  server  running,
       prompting for usernames and passwords, and starting up the
       user sessions.

       Installations that run more than  one  window  system  may
       need to use the xinit(1) utility instead of xdm.  However,
       xinit is to be considered  a  tool  for  building  startup
       scripts  and  is  not intended for use by end users.  Site
       administrators are strongly urged to  use  xdm,  or  build
       other interfaces for novice users.

       The  X  server  may  also be started directly by the user,
       though this method is usually reserved for testing and  is
       not  recommended for normal operation.  On some platforms,
       the user must have  special  permission  to  start  the  X
       server,  often  because  access  to  certain devices (e.g.
       /dev/mouse) is restricted.

       When the X server starts up, it typically takes  over  the
       display.   If  you are running on a workstation whose con-
       sole is the display, you may not be able to log  into  the
       console while the server is running.

OPTIONS
       All  of  the  X  servers accept the following command line
       options:

       :displaynumber
               the X server  runs  as  the  given  displaynumber,
               which  by default is 0.  If multiple X servers are
               to run simultaneously on a host, each must have  a
               unique display number.  See the DISPLAY NAMES sec-
               tion of the X(1) manual page to learn how to spec-
               ify  which  display  number  clients should try to
               use.

       -a number
               sets pointer acceleration (i.e. the ratio  of  how
               much  is  reported  to  how much the user actually
               moved the pointer).

       -ac     disables  host-based  access  control  mechanisms.
               Enables  access  by any host, and permits any host
               to modify  the  access  control  list.   Use  with
               extreme caution.  This option exists primarily for
               running test suites remotely.

       -audit level
               Sets the audit trail level.  The default level  is
               1,   meaning   only   connection   rejections  are
               reported.  Level 2 additionally reports  all  suc-
               cessful  connections  and  disconnects.   Level  4
               enables messages from the SECURITY  extension,  if
               present,  including  generation  and revocation of
               authorizations and violations of the security pol-
               icy.   Level  0  turns off the audit trail.  Audit
               lines are sent as standard error output.

       -auth authorization-file
               Specifies a file which contains  a  collection  of
               authorization records used to authenticate access.
               See also the xdm and Xsecurity manual pages.

       bc      disables certain kinds of error checking, for  bug
               compatibility  with  previous  releases  (e.g., to
               work around bugs in R2 and R3  xterms  and  toolk-
               its).  Deprecated.

       -bs     disables backing store support on all screens.

       -c      turns off key-click.

       c volume
               sets key-click volume (allowable range: 0-100).

       -cc class
               sets the visual class for the root window of color
               screens.  The class numbers are  as  specified  in
               the X protocol.  Not obeyed by all servers.

       -co filename
               sets  name  of RGB color database.  The default is
               <XRoot>/lib/X11/rgb, where <XRoot> refers  to  the
               root of the X11 install tree.

       -core   causes the server to generate a core dump on fatal
               errors.

       -dpi resolution
               sets the resolution of the  screen,  in  dots  per
               inch.  To be used when the server cannot determine
               the screen size from the hardware.

       dpms    Enable DPMS (when supported).

       -dpms   Disable DPMS.

       -deferglyphs whichfonts
               specifies the types of fonts for which the  server
               should  attempt  to  use  deferred  glyph loading.
               whichfonts  can  be  all  (all  fonts),  none  (no
               fonts), or 16 (16 bit fonts only).

       -f volume
               sets  feep (bell) volume (allowable range: 0-100).

       -fc cursorFont
               sets default cursor font.

       -fn font
               sets the default font.

       -fp fontPath
               sets the search path for fonts.  This  path  is  a
               comma  separated  list  of directories which the X
               server searches for font databases.

       -help   prints a usage message.

       -I      causes all remaining command line arguments to  be
               ignored.

       -kb     disables the XKEYBOARD extension if present.

       -nolisten trans-type
               Disable  a  transport  type.   For example, TCP/IP
               connections can be disabled with -nolisten tcp

       -nolock Disable the use of an X server lock file.

       -p minutes
               sets screen-saver pattern cycle time in minutes.

       -pn     permits the server to continue running if it fails
               to  establish  all of its well-known sockets (con-
               nection points for clients),  but  establishes  at
               least one.

       -r      turns off auto-repeat.

       r       turns on auto-repeat.

       -s minutes
               sets screen-saver timeout time in minutes.

       -su     disables save under support on all screens.

       -t number
               sets  pointer  acceleration  threshold  in  pixels
               (i.e. after how many pixels  pointer  acceleration
               should take effect).

       -terminate
               causes  the  server  to terminate at server reset,
               instead of continuing to run.

       -to seconds
               sets default connection timeout in seconds.

       -tst    disables  all  testing  extensions  (e.g.,  XTEST,
               XTrap, XTestExtension1, RECORD).

       ttyxx   ignored, for servers started the ancient way (from
               init).

       v       sets video-off screen-saver preference.

       -v      sets video-on screen-saver preference.

       -wm     forces the default backing-store of all windows to
               be  WhenMapped.  This is a backdoor way of getting
               backing-store to apply to all  windows.   Although
               all  mapped  windows  will have backing store, the
               backing store  attribute  value  reported  by  the
               all  mapped  windows  will have backing store, the
               backing store  attribute  value  reported  by  the
               server  for a window will be the last value estab-
               lished by a client.  If it has never been set by a
               client,  the server will report the default value,
               NotUseful.  This behavior is  required  by  the  X
               protocol,  which  allows  the server to exceed the
               client's backing store expectations but  does  not
               provide  a way to tell the client that it is doing
               so.

       -x extension
               loads the specified extension at init.  This is  a
               no-op for most implementations.

SERVER DEPENDENT OPTIONS
       Some X servers accept the following options:

       -ld kilobytes
               sets  the  data  space  limit of the server to the
               specified number of kilobytes.  A  value  of  zero
               makes  the  data  size  as large as possible.  The
               default value of -1 leaves the  data  space  limit
               unchanged.



       -lf files
               sets  the number-of-open-files limit of the server
               to the specified number.  A value  of  zero  makes
               the limit as large as possible.  The default value
               of -1 leaves the limit unchanged.

       -ls kilobytes
               sets the stack space limit of the  server  to  the
               specified  number  of  kilobytes.  A value of zero
               makes the stack size as large  as  possible.   The
               default  value  of -1 leaves the stack space limit
               unchanged.

       -logo   turns on the X Window System logo display  in  the
               screen-saver.  There is currently no way to change
               this from a client.

       nologo  turns off the X Window System logo display in  the
               screen-saver.  There is currently no way to change
               this from a client.

XDMCP OPTIONS
       X servers that support XDMCP have the  following  options.
       See  the  X Display Manager Control Protocol specification
       for more information.

       -query host-name
               Enable XDMCP and send Query packets to the  speci-
               fied host.

       -broadcast
               Enable  XDMCP and broadcast BroadcastQuery packets
               to the network.  The first responding display man-
               ager will be chosen for the session.

       -indirect host-name
               Enable XDMCP and send IndirectQuery packets to the
               specified host.

       -port port-num
               Use an alternate port number  for  XDMCP  packets.
               Must be specified before any -query, -broadcast or
               -indirect options.

       -class display-class
               XDMCP has an additional display qualifier used  in
               resource   lookup  for  display-specific  options.
               This option sets that  value,  by  default  it  is
               "MIT-Unspecified" (not a very useful value).

       -cookie xdm-auth-bits
               When  testing  XDM-AUTHENTICATION-1, a private key
               is shared between  the  server  and  the  manager.
               This  option  sets  the value of that private data
               (not that it is very private, being on the command
               line!).

       -displayID display-id
               Yet  another XDMCP specific value, this one allows
               the display manager to identify  each  display  so
               that it can locate the shared key.

XKEYBOARD OPTIONS
       X  servers that support the XKEYBOARD extension accept the
       following options:

       -xkbmap filename
               keyboard description to load on startup

       [+-]accessx
               enable(+) or disable(-) AccessX key sequences

       -ar1 milliseconds
               sets the length of time in milliseconds that a key
               must be depressed before autorepeat starts

       -ar2 milliseconds
               sets  the  length  of  time  in  milliseconds that
               should   elapse    between    autorepeat-generated
               keystrokes

       Many   servers  also  have  device-specific  command  line
       options.  See the manual pages for the individual  servers
       for more details.

SECURITY EXTENSION OPTIONS
       X  servers  that support the SECURITY extension accept the
       following option:

       -sp filename
               causes the server to attempt to read and interpret
               filename as a security policy file with the format
               described below.   The  file  is  read  at  server
               startup and reread at each server reset.

       The  syntax  of  the  security  policy file is as follows.
       Notation: "*" means zero or more occurrences of  the  pre-
       ceding element, and "+" means one or more occurrences.  To
       interpret <foo/bar>, ignore the text after the  /;  it  is
       used to distinguish between instances of <foo> in the next
       section.

       <policy file> ::= <version line> <other line>*

       <version line> ::= <string/v> '\n'

       <other line > ::= <comment> | <access rule> | <site policy> | <blank line

       <comment> ::= # <not newline>* '\n'

       <blank line> ::= <space> '\n'

       <site policy> ::= sitepolicy <string/sp> '\n'

       <access rule> ::= property <property/ar> <window> <perms> '\n'

       <property> ::= <string>

       <window> ::= any | root | <required property>

       <required property> ::= <property/rp> | <property with value>

       <property with value> ::= <property/rpv> = <string/rv>

       <perms> ::= [ <operation> | <action> | <space> ]*

       <operation> ::= r | w | d

       <action> ::= a | i | e

       <string> ::= <dbl quoted string> | <single quoted string> | <unqouted string>

       <dbl quoted string> ::= <space> " <not dqoute>* " <space>

       <single quoted string> ::= <space> ' <not squote>* ' <space>

       <unquoted string> ::= <space> <not space>+ <space>

       <space> ::= [ ' ' | '\t' ]*

       Character sets:

       <not newline> ::= any character except '\n'
       <not dqoute>  ::= any character except "
       <not squote>  ::= any character except '
       <not space>   ::= any character except those in <space>

       The semantics associated with the above syntax are as fol-
       lows.

       <version  line>, the first line in the file, specifies the
       file format version.  If the server does not recognize the
       version  <string/v>, it ignores the rest of the file.  The
       version string for the file format described here is "ver-
       sion-1" .

       Once  past the <version line>, lines that do not match the
       above syntax are ignored.

       <comment> lines are ignored.

       <sitepolicy>  lines  are  currently  ignored.   They   are
       intended  to  specify  the  site  policies used by the XC-
       QUERY-SECURITY-1 authorization method.

       <access rule> lines specify how the server should react to
       untrusted  client  requests that affect the X Window prop-
       erty  named  <property/ar>.   The  rest  of  this  section
       describes the interpretation of an <access rule>.

       For  an  <access  rule>  to  apply  to a given instance of
       <property/ar>, <property/ar> must be on a window  that  is
       in  the set of windows specified by <window>.  If <window>
       is any, the rule applies to <property/ar> on  any  window.
       If  <window>  is  root,  the rule applies to <property/ar>
       only on root windows.

       If <window> is <required property>, the  following  apply.
       If  <required  property>  is  a  <property/rp>,  the  rule
       applies when  the  window  also  has  that  <property/rp>,
       regardless  of  its  value.   If  <required property> is a
       <property with value>, <property/rpv> must also  have  the
       value  specified  by <string/rv>.  In this case, the prop-
       erty must have type STRING and format 8, and  should  con-
       tain  one  or more null-terminated strings.  If any of the
       strings match <string/rv>, the rule applies.

       The definition of string matching is simple case-sensitive
       string  comparison  with one elaboration: the occurence of
       the character '*' in <string/rv>  is  a  wildcard  meaning
       "any  string."   A  <string/rv> can contain multiple wild-
       cards anywhere in the string.  For example,  "x*"  matches
       strings  that  begin with x, "*x" matches strings that end
       with x, "*x*" matches strings  containing  x,  and  "x*y*"
       matches strings that start with x and subsequently contain
       y.

       There may be multiple <access  rule>  lines  for  a  given
       <property/ar>.   The  rules  are  tested in the order that
       they appear in the file.  The first rule that  applies  is
       used.

       <perms>  specify  operations  that  untrusted  clients may
       attempt, and the actions that the server  should  take  in
       response to those operations.

       <operation>  can  be  r  (read), w (write), or d (delete).
       The following table shows how X Protocol property requests
       map  to these operations in the X Consortium server imple-
       mentation.

       GetProperty    r, or r and d if delete = True
       ChangeProperty w
       RotateProperties    r and w
       DeleteProperty d
       ListProperties none, untrusted clients can always list all properties

       <action> can be a  (allow),  i  (ignore),  or  e  (error).
       Allow  means  execute the request as if it had been issued
       by a trusted client.  Ignore means treat the request as  a
       no-op.  In the case of GetProperty, ignore means return an
       empty property value if the property exists, regardless of
       its  actual value.  Error means do not execute the request
       and return a BadAtom error with the atom set to the  prop-
       erty  name.   Error  is the default action for all proper-
       ties, including those not listed in  the  security  policy
       file.

       An  <action>  applies  to all <operation>s that follow it,
       until the  next  <action>  is  encountered.   Thus,  irwad
       means ignore read and write, allow delete.

       GetProperty  and  RotateProperties  may do multiple opera-
       tions (r and d, or r and w).  If different  actions  apply
       to  the  operations,  the most severe action is applied to
       the whole request; there is no partial request  execution.
       The  severity  ordering is: allow < ignore < error.  Thus,
       if the <perms> for a property are ired (ignore read, error
       delete),  and  an untrusted client attempts GetProperty on
       that property with delete = True, an  error  is  returned,
       but  the  property value is not.  Similarly, if any of the
       properties in a RotateProperties do not  allow  both  read
       and write, an error is returned without changing any prop-
       erty values.

       Here is an example security policy file.

       version-1

       # Allow reading of application resources, but not writing.
       property RESOURCE_MANAGER     root      ar iw
       property SCREEN_RESOURCES     root      ar iw

       # Ignore attempts to use cut buffers.  Giving errors causes apps to crash
       # and allowing access may give away too much information.
       property CUT_BUFFER0          root      irw
       property CUT_BUFFER1          root      irw
       property CUT_BUFFER2          root      irw
       property CUT_BUFFER3          root      irw
       property CUT_BUFFER4          root      irw
       property CUT_BUFFER5          root      irw
       property CUT_BUFFER6          root      irw
       property CUT_BUFFER7          root      irw

       # If you are using Motif, you probably want these.
       property _MOTIF_DEFAULT_BINDINGS        rootar iw
       property _MOTIF_DRAG_WINDOW   root      ar iw
       property _MOTIF_DRAG_TARGETS  any       ar iw
       property _MOTIF_DRAG_ATOMS    any       ar iw
       property _MOTIF_DRAG_ATOM_PAIRS         any ar iw

       # The next two rules let xwininfo -tree work when untrusted.
       property WM_NAME              any       ar

       # Allow read of WM_CLASS, but only for windows with WM_NAME.
       # This might be more restrictive than necessary, but demonstrates
       # the <required property> facility, and is also an attempt to
       # say "top level windows only."
       property WM_CLASS             WM_NAME   ar

       # These next three let xlsclients work untrusted.  Think carefully
       # before including these; giving away the client machine name and command       # may be exposing too much.
       property WM_STATE             WM_NAME   ar
       property WM_CLIENT_MACHINE    WM_NAME   ar
       property WM_COMMAND           WM_NAME   ar

       # To let untrusted clients use the standard colormaps created by
       # xstdcmap, include these lines.
       property RGB_DEFAULT_MAP      root      ar
       property RGB_BEST_MAP         root      ar
       property RGB_RED_MAP          root      ar
       property RGB_GREEN_MAP        root      ar
       property RGB_BLUE_MAP         root      ar
       property RGB_GRAY_MAP         root      ar

       # To let untrusted clients use the color management database created
       # by xcmsdb, include these lines.
       property XDCCC_LINEAR_RGB_CORRECTION    rootar
       property XDCCC_LINEAR_RGB_MATRICES      rootar
       property XDCCC_GRAY_SCREENWHITEPOINT    rootar
       property XDCCC_GRAY_CORRECTION          rootar

       # To let untrusted clients use the overlay visuals that many vendors
       # support, include this line.
       property SERVER_OVERLAY_VISUALS         rootar

       # Dumb examples to show other capabilities.

       # oddball property names and explicit specification of error conditions
       property "property with spaces"         'property with "'aw er ed

       # Allow deletion of Woo-Hoo if window also has property OhBoy with value
       # ending in "son".  Reads and writes will cause an error.
       property Woo-Hoo              OhBoy = "*son"ad

NETWORK CONNECTIONS
       The X server supports client connections via  a  platform-
       dependent  subset of the following transport types: TCPIP,
       Unix Domain sockets, DECnet, and several varieties of SVR4
       local  connections.   See the DISPLAY NAMES section of the
       X(1) manual page to learn how to specify  which  transport
       type clients should try to use.

GRANTING ACCESS
       The X server implements a platform-dependent subset of the
       following  authorization  protocols:   MIT-MAGIC-COOKIE-1,
       XDM-AUTHORIZATION-1,  SUN-DES-1,  and MIT-KERBEROS-5.  See
       the Xsecurity(1) manual page for information on the opera-
       tion of these protocols.

       Authorization  data  required  by  the  above protocols is
       passed to the server in a  private  file  named  with  the
       -auth  command line option.  Each time the server is about
       to accept the first connection after a reset (or when  the
       server  is  starting),  it  reads this file.  If this file
       contains any authorization records, the local host is  not
       automatically  allowed  access  to  the  server,  and only
       clients which send one of the authorization  records  con-
       tained  in  the  file  in the connection setup information
       will be allowed access.  See the Xau  manual  page  for  a
       description  of  the  binary  format  of  this  file.  See
       xauth(1) for maintenance of this file, and distribution of
       its contents to remote hosts.

       The  X  server  also uses a host-based access control list
       for deciding whether or not  to  accept  connections  from
       clients  on  a particular machine.  If no other authoriza-
       tion mechanism is being used, this list initially consists
       of  the host on which the server is running as well as any
       machines listed in the file /etc/Xn.hosts, where n is  the
       display  number  of  the  server.   Each  line of the file
       should  contain  either   an   Internet   hostname   (e.g.
       expo.lcs.mit.edu)  or  a  DECnet  hostname in double colon
       format (e.g. hydra::).  There  should  be  no  leading  or
       trailing spaces on any lines.  For example:

               joesworkstation
               corporate.company.com
               star::
               bigcpu::

       Users can add or remove hosts from this list and enable or
       disable access control using the xhost  command  from  the
       same machine as the server.

       The  X  protocol intrinsically does not have any notion of
       window operation permissions or place any restrictions  on
       what  a  client can do; if a program can connect to a dis-
       play, it has full run of the screen.  X servers that  sup-
       port  the  SECURITY  extension fare better because clients
       can be designated untrusted via the authorization they use
       to  connect;  see  the  xauth(1)  manual page for details.
       Restrictions are imposed on untrusted clients that curtail
       the  mischief  they  can  do.   See the SECURITY extension
       specification for a complete list of these restrictions.

       Sites that have better  authentication  and  authorization
       systems  might  wish  to  make  use  of  the  hooks in the
       libraries and the server to  provide  additional  security
       models.

SIGNALS
       The  X  server  attaches  special meaning to the following
       signals:

       SIGHUP  This signal causes the server to close all  exist-
               ing  connections,  free all resources, and restore
               all defaults.  It is sent by the  display  manager
               whenever the main user's main application (usually
               an xterm or window manager)  exits  to  force  the
               server  to clean up and prepare for the next user.

       SIGTERM This signal causes the server to exit cleanly.

       SIGUSR1 This signal is used quite differently from  either
               of  the  above.  When the server starts, it checks
               to see if it  has  inherited  SIGUSR1  as  SIG_IGN
               instead  of  the usual SIG_DFL.  In this case, the
               server sends a SIGUSR1 to its parent process after
               it has set up the various connection schemes.  Xdm
               uses this feature to recognize when connecting  to
               the server is possible.

FONTS
       The X server can obtain fonts from directories and/or from
       font servers.  The list of directories  and  font  servers
       the X server uses when trying to open a font is controlled
       by the font path.

       The default  font  path  is  "<XRoot>/lib/X11/fonts/misc/,
       <XRoot>/lib/X11/fonts/Speedo/,
       <XRoot>/lib/X11/fonts/Type1/,
       <XRoot>/lib/X11/fonts/75dpi/,
       <XRoot>/lib/X11/fonts/100dpi/" .  where <XRoot> refers  to
       the root of the X11 install tree.

       The font path can be set with the -fp option or by xset(1)
       after the server has started.

FILES
       /etc/Xn.hosts                 Initial access control  list
                                     for display number n

       <XRoot>/lib/X11/fonts/misc,
                                     <XRoot>/lib/X11/fonts/75dpi,
                                     <XRoot>/lib/X11/fonts/100dpi
                                     Bitmap font directories


       <XRoot>/lib/X11/fonts/Speedo, <XRoot>/lib/X11/fonts/Type1
                                     Outline font directories

       <XRoot>/lib/X11/fonts/PEX     PEX font directories

       <XRoot>/lib/X11/rgb.txt       Color database

       /tmp/.X11-unix/Xn             Unix  domain socket for dis-
                                     play number n

       /tmp/rcXn                     Kerberos 5 replay cache  for
                                     display number n

       /usr/adm/Xnmsgs               Error  log  file for display
                                     number n if run from init(8)

       <XRoot>/lib/X11/xdm/xdm-errors
                                     Default  error  log  file if
                                     the  server  is   run   from
                                     xdm(1)

       Note:  <XRoot> refers to the root of the X11 install tree.

SEE ALSO
       General information: X(1)

       Protocols: X Window System Protocol, The  X  Font  Service
       Protocol, X Display Manager Control Protocol

       Fonts:  bdftopcf(1),  mkfontdir(1),  xfs(1),  xlsfonts(1),
       xfontsel(1), xfd(1), X Logical  Font  Description  Conven-
       tions

       Security:    Xsecurity(1),   xauth(1),   Xau(1),   xdm(1),
       xhost(1), Security Extension Specification

       Starting the server: xdm(1), xinit(1)

       Controlling the server once started: xset(1), xsetroot(1),
       xhost(1)

       Server-specific  man  pages:  Xdec(1), XmacII(1), Xsun(1),
       Xnest(1),    Xvfb(1),     XF86_Accel(1),     XF86_Mono(1),
       XF86_SVGA(1), XF86_VGA16(1), XFree86(1)

       Server  internal  documentation: Definition of the Porting
       Layer for the X v11 Sample Server

AUTHORS
       The sample server was originally written  by  Susan  Ange-
       branndt,  Raymond Drewry, Philip Karlton, and Todd Newman,
       from Digital Equipment Corporation, with  support  from  a
       large  cast.   It  has since been extensively rewritten by
       Keith Packard and Bob Scheifler, from MIT.   Dave  Wiggins
       took over post-R5 and made substantial improvements.

X Version 11               Release 6.3                          1




""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""


XSECURITY(1)                                         XSECURITY(1)

NAME
       Xsecurity - X display access control

SYNOPSIS
       X  provides mechanism for implementing many access control
       systems.  The sample implementation includes  five  mecha-
       nisms:
           Host Access                   Simple host-based access control.
           MIT-MAGIC-COOKIE-1            Shared plain-text "cookies".
           XDM-AUTHORIZATION-1           Secure DES based private-keys.
           SUN-DES-1                     Based on Sun's secure rpc system.
           MIT-KERBEROS-5                Kerberos Version 5 user-to-user.

ACCESS SYSTEM DESCRIPTIONS
       Host Access
              Any  client  on  a  host in the host access control
              list is allowed access to the X server.  This  sys-
              tem  can  work  reasonably  well  in an environment
              where everyone trusts everyone, or when only a sin-
              gle  person  can  log in to a given machine, and is
              easy to use when the list of hosts used  is  small.
              This system does not work well when multiple people
              can log in to a single  machine  and  mutual  trust
              does  not  exist.   The  list  of  allowed hosts is
              stored in the X server and can be changed with  the
              xhost  command.   When using the more secure mecha-
              nisms listed below, the host list is normally  con-
              figured  to  be the empty list, so that only autho-
              rized programs can connect to the display.

       MIT-MAGIC-COOKIE-1
              When using MIT-MAGIC-COOKIE-1, the client  sends  a
              128  bit  "cookie"  along with the connection setup
              information.  If the cookie presented by the client
              matches  one  that the X server has, the connection
              is allowed access.  The cookie is chosen so that it
              is  hard to guess; xdm generates such cookies auto-
              matically when this form of access control is used.
              The  user's copy of the cookie is usually stored in
              the  .Xauthority  file  in  the   home   directory,
              although the environment variable XAUTHORITY can be
              used to specify an alternate location.   Xdm  auto-
              matically  passes  a  cookie to the server for each
              new login session, and stores  the  cookie  in  the
              user file at login.

              The  cookie  is  transmitted on the network without
              encryption, so there is nothing to prevent  a  net-
              work  snooper  from obtaining the data and using it
              to gain access to the X  server.   This  system  is
              useful  in an environment where many users are run-
              ning applications on the same machine and  want  to
              avoid interference from each other, with the caveat
              that this control is only as  good  as  the  access
              control  to  the physical network.  In environments
              where network-level  snooping  is  difficult,  this
              system can work reasonably well.

       XDM-AUTHORIZATION-1
              Sites  in  the  United  States  can use a DES-based
              access  control  mechanism  called   XDM-AUTHORIZA-
              TION-1.   It  is  similar  in  usage  to MIT-MAGIC-
              COOKIE-1 in that a key is stored in the .Xauthority
              file  and  is  shared  with the X server.  However,
              this key consists of two  parts  -  a  56  bit  DES
              encryption  key  and 64 bits of random data used as
              the authenticator.

              When connecting to the X  server,  the  application
              generates 192 bits of data by combining the current
              time in seconds (since 00:00  1/1/1970  GMT)  along
              with  48  bits of "identifier".  For TCP/IP connec-
              tions, the identifier is the address plus port num-
              ber; for local connections it is the process ID and
              32 bits to form a unique id (in case multiple  con-
              nections  to the same server are made from a single
              process).  This 192 bit packet  is  then  encrypted
              using  the  DES key and sent to the X server, which
              is able to verify if the requestor is authorized to
              connect  by  decrypting  with  the same DES key and
              validating the authenticator and  additional  data.
              This  system  is  useful in many environments where
              host-based  access  control  is  inappropriate  and
              where network security cannot be ensured.

       SUN-DES-1
              Recent  versions  of SunOS (and some other systems)
              have included a secure public key remote  procedure
              call system.  This system is based on the notion of
              a network principal; a user  name  and  NIS  domain
              pair.  Using this system, the X server can securely
              discover the actual user  name  of  the  requesting
              process.   It  involves  encrypting data with the X
              server's public key, and so  the  identity  of  the
              user  who  started the X server is needed for this;
              this identity is stored in  the  .Xauthority  file.
              By  extending  the  semantics  of "host address" to
              include this notion of network principal, this form
              of access control is very easy to use.

              To  allow  access  by  a  new user, use xhost.  For
              example,
                  xhost keith@ ruth@mit.edu
              adds "keith" from  the  NIS  domain  of  the  local
              machine,  and  "ruth"  in the "mit.edu" NIS domain.
              For keith or ruth to successfully  connect  to  the
              display,  they  must  add the principal who started
              the server to their .Xauthority file.  For example:
                  xauth add expo.lcs.mit.edu:0 SUN-DES-1 unix.expo.lcs.mit.edu@our.domain.edu
              This  system  only  works on machines which support
              Secure RPC, and only for users which  have  set  up
              the  appropriate  public/private key pairs on their
              system.   See  the  Secure  RPC  documentation  for
              details.  To access the display from a remote host,
              you may have to do a keylogin on  the  remote  host
              first.

       MIT-KERBEROS-5
              Kerberos  is  a network-based authentication scheme
              developed by MIT for  Project  Athena.   It  allows
              mutually suspicious principals to authenticate each
              other as long as each trusts a  third  party,  Ker-
              beros.   Each principal has a secret key known only
              to it and Kerberos.  Principals  includes  servers,
              such as an FTP server or X server, and human users,
              whose key is their password.  Users gain access  to
              services by getting Kerberos tickets for those ser-
              vices from a Kerberos server.  Since the  X  server
              has  no place to store a secret key, it shares keys
              with the user who logs in.  X  authentication  thus
              uses the user-to-user scheme of Kerberos version 5.

              When you log in via xdm, xdm will use your password
              to obtain the initial Kerberos tickets.  xdm stores
              the tickets in a credentials cache  file  and  sets
              the environment variable KRB5CCNAME to point to the
              file.  The credentials cache is destroyed when  the
              session  ends  to  reduce the chance of the tickets
              being stolen before they expire.

              Since Kerberos is a user-based authorization proto-
              col,  like  the  SUN-DES-1 protocol, the owner of a
              display can enable and disable specific  users,  or
              Kerberos  principals.   The xhost client is used to
              enable or disable authorization.  For example,
                  xhost krb5:judy krb5:gildea@x.org
              adds "judy" from the Kerberos realm  of  the  local
              machine, and "gildea" from the "x.org" realm.

THE AUTHORIZATION FILE
       Except for Host Access control, each of these systems uses
       data stored in the .Xauthority file to generate  the  cor-
       rect  authorization  information  to  pass  along to the X
       server at connection setup.  MIT-MAGIC-COOKIE-1  and  XDM-
       AUTHORIZATION-1  store  secret data in the file; so anyone
       who can read the file can gain access  to  the  X  server.
       SUN-DES-1  stores  only  the identity of the principal who
       started the server (unix.hostname@domain when  the  server
       is  started by xdm), and so it is not useful to anyone not
       authorized to connect to the server.

       Each entry in the .Xauthority file matches a certain  con-
       nection family (TCP/IP, DECnet or local connections) and X
       display name (hostname plus display number).  This  allows
       multiple  authorization  entries for different displays to
       share the same data file.   A  special  connection  family
       (FamilyWild,  value  65535) causes an entry to match every
       display, allowing the entry to be  used  for  all  connec-
       tions.  Each entry additionally contains the authorization
       name and whatever private authorization data is needed  by
       that  authorization  type to generate the correct informa-
       tion at connection setup time.

       The xauth program manipulates the .Xauthority file format.
       It  understands  the  semantics of the connection families
       and address formats, displaying them in an easy to  under-
       stand format.  It also understands that SUN-DES-1 and MIT-
       KERBEROS-5 use string values for the  authorization  data,
       and displays them appropriately.

       The  X server (when running on a workstation) reads autho-
       rization information from a file name passed on  the  com-
       mand  line  with  the -auth option (see the Xserver manual
       page).  The authorization entries in the file are used  to
       control  access  to the server.  In each of the authoriza-
       tion schemes listed above, the data needed by  the  server
       to  initialize an authorization scheme is identical to the
       data needed by the  client  to  generate  the  appropriate
       authorization information, so the same file can be used by
       both processes.  This is especially useful when  xinit  is
       used.

       MIT-MAGIC-COOKIE-1
              This  system  uses  128 bits of data shared between
              the user and the X server.  Any collection of  bits
              can  be  used.   Xdm  generates  these keys using a
              cryptographically secure pseudo random number  gen-
              erator,  and  so the key to the next session cannot
              be computed from the current session key.

       XDM-AUTHORIZATION-1
              This system uses two pieces of information.  First,
              64 bits of random data, second a 56 bit DES encryp-
              tion key (again, random data) stored  in  8  bytes,
              the  last  byte of which is ignored.  Xdm generates
              these keys using the same random  number  generator
              as is used for MIT-MAGIC-COOKIE-1.

       SUN-DES-1
              This  system  needs  a string representation of the
              principal which identifies the associated X server.
              This  information  is  used to encrypt the client's
              authority information when it  is  sent  to  the  X
              server.   When xdm starts the X server, it uses the
              root principal for the machine on which it is  run-
              ning          (unix.hostname@domain,          e.g.,
              "unix.expire.lcs.mit.edu@our.domain.edu").  Putting
              the  correct principal name in the .Xauthority file
              causes Xlib to generate the appropriate  authoriza-
              tion information using the secure RPC library.

       MIT-KERBEROS-5
              Kerberos reads tickets from the cache pointed to by
              the KRB5CCNAME environment variable,  so  does  not
              use  any  data from the .Xauthority file.  An entry
              with no data must still exist to tell clients  that
              MIT-KERBEROS-5 is available.

              Unlike   the  .Xauthority  file  for  clients,  the
              authority file passed by xdm to a  local  X  server
              (with  ``-auth filename'', see xdm(1)) does contain
              the name of the  credentials  cache,  since  the  X
              server  will  not  have  the KRB5CCNAME environment
              variable set.  The data of the MIT-KERBEROS-5 entry
              is  the  credentials  cache  name  and has the form
              ``UU:FILE:filename'', where filename is the name of
              the  credentials  cache  file created by xdm.  Note
              again that this form is not used by clients.

FILES
       .Xauthority

SEE ALSO
       X(1), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)

X Version 11               Release 6.3                          1


""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""


XDM(1)                                                     XDM(1)

NAME
       xdm  -  X  Display  Manager  with  support for XDMCP, host
       chooser

SYNOPSIS
       xdm [ -config configuration_file ] [ -nodaemon ] [  -debug
       debug_level  ]  [  -error  error_log_file  ]  [ -resources
       resource_file ] [ -server server_entry ] [  -session  ses-
       sion_program ]

DESCRIPTION
       Xdm  manages  a  collection of X displays, which may be on
       the local host or remote servers.  The design of  xdm  was
       guided  by  the needs of X terminals as well as the X Con-
       sortium standard XDMCP, the X Display Manager Control Pro-
       tocol.  Xdm provides services similar to those provided by
       init, getty and login on  character  terminals:  prompting
       for  login name and password, authenticating the user, and
       running a ``session.''

       A ``session'' is defined by the lifetime of  a  particular
       process;   in  the  traditional  character-based  terminal
       world, it is the user's login shell.  In the xdm  context,
       it  is an arbitrary session manager.  This is because in a
       windowing environment, a user's login shell  process  does
       not  necessarily  have  any  terminal-like  interface with
       which to connect.  When a  real  session  manager  is  not
       available,  a window manager or terminal emulator is typi-
       cally used as the ``session manager,'' meaning that termi-
       nation of this process terminates the user's session.

       When  the  session  is terminated, xdm resets the X server
       and (optionally) restarts the whole process.

       When xdm receives an Indirect query via XDMCP, it can  run
       a  chooser  process to perform an XDMCP BroadcastQuery (or
       an XDMCP Query to specified hosts) on behalf of  the  dis-
       play  and  offer a menu of possible hosts that offer XDMCP
       display management.  This feature is useful with X  termi-
       nals that do not offer a host menu themselves.

       Xdm  can  be  configured to ignore BroadcastQuery messages
       from selected hosts.  This is useful when you  don't  want
       the  host to appear in menus produced by chooser or X ter-
       minals themselves.

       Because xdm provides the first interface that  users  will
       see,  it  is designed to be simple to use and easy to cus-
       tomize to the needs of a particular site.   Xdm  has  many
       options,  most  of which have reasonable defaults.  Browse
       through the various sections of this manual,  picking  and
       choosing  the  things  you want to change.  Pay particular
       attention to  the  Session  Program  section,  which  will
       describe how to set up the style of session desired.

OVERVIEW
       xdm  is  highly configurable, and most of its behavior can
       be controlled by resource files and  shell  scripts.   The
       names  of  these  files themselves are resources read from
       the file xdm-config or  the  file  named  by  the  -config
       option.

       xdm  offers display management two different ways.  It can
       manage X servers running on the local machine  and  speci-
       fied in Xservers, and it can manage remote X servers (typ-
       ically X terminals) using XDMCP (the XDM Control Protocol)
       as specified in the Xaccess file.

       The  resources  of  the  X  clients run by xdm outside the

       Because xdm provides the first interface that  users  will
       see,  it  is designed to be simple to use and easy to cus-
       tomize to the needs of a particular site.   Xdm  has  many
       options,  most  of which have reasonable defaults.  Browse
       through the various sections of this manual,  picking  and
       choosing  the  things  you want to change.  Pay particular
       attention to  the  Session  Program  section,  which  will
       describe how to set up the style of session desired.

OVERVIEW
       xdm  is  highly configurable, and most of its behavior can
       be controlled by resource files and  shell  scripts.   The
       names  of  these  files themselves are resources read from
       the file xdm-config or  the  file  named  by  the  -config
       option.

       xdm  offers display management two different ways.  It can
       manage X servers running on the local machine  and  speci-
       fied in Xservers, and it can manage remote X servers (typ-
       ically X terminals) using XDMCP (the XDM Control Protocol)
       as specified in the Xaccess file.

       The  resources  of  the  X  clients run by xdm outside the

       Because xdm provides the first interface that  users  will
       see,  it  is designed to be simple to use and easy to cus-
       tomize to the needs of a particular site.   Xdm  has  many
       options,  most  of which have reasonable defaults.  Browse
       through the various sections of this manual,  picking  and
       choosing  the  things  you want to change.  Pay particular
       attention to  the  Session  Program  section,  which  will
       describe how to set up the style of session desired.

OVERVIEW
       xdm  is  highly configurable, and most of its behavior can
       be controlled by resource files and  shell  scripts.   The
       names  of  these  files themselves are resources read from
       the file xdm-config or  the  file  named  by  the  -config
       option.

       xdm  offers display management two different ways.  It can
       manage X servers running on the local machine  and  speci-
       fied in Xservers, and it can manage remote X servers (typ-
       ically X terminals) using XDMCP (the XDM Control Protocol)
       as specified in the Xaccess file.

       The  resources  of  the  X  clients run by xdm outside the
       user's session, including xdm's own login window,  can  be
       affected by setting resources in the Xresources file.

       For  X  terminals that do not offer a menu of hosts to get
       display management from, xdm can collect willing hosts and
       run  the  chooser program to offer the user a menu.  For X
       displays attached to a host, this step  is  typically  not
       used, as the local host does the display management.

       After  resetting  the X server, xdm runs the Xsetup script
       to assist in setting up the screen  the  user  sees  along
       with the xlogin widget.

       The xlogin widget, which xdm presents, offers the familiar
       login and password prompts.

       After the user logs in, xdm runs the  Xstartup  script  as
       root.

       Then  xdm runs the Xsession script as the user.  This sys-
       tem session file may do some additional startup and  typi-
       cally  runs the .xsession script in the user's home direc-
       tory.  When the Xsession  script  exits,  the  session  is
       over.

       At  the  end  of  the session, the Xreset script is run to
       clean up, the X server is  reset,  and  the  cycle  starts
       over.

       The  file  /usr/X11R6/lib/X11/xdm/xdm-errors  will contain
       error messages from xdm and anything output to  stderr  by
       Xsetup, Xstartup, Xsession or Xreset.  When you have trou-
       ble getting xdm working, check this file to see if xdm has
       any clues to the trouble.

OPTIONS
       All  of these options, except -config itself, specify val-
       ues that can also be specified in the  configuration  file
       as resources.

       -config configuration_file
              Names   the  configuration  file,  which  specifies
              resources  to  control   the   behavior   of   xdm.
              <XRoot>/lib/X11/xdm/xdm-config is the default.  See
              the section Configuration File.

       -nodaemon
              Specifies ``false'' as the value for  the  Display-
              Manager.daemonMode  resource.   This suppresses the
              normal daemon behavior, which is for xdm  to  close
              all  file descriptors, disassociate itself from the
              controlling terminal, and put itself in  the  back-
              ground when it first starts up.

       -debug debug_level
              Specifies  the  numeric  value  for the DisplayMan-
              ager.debugLevel resource.  A non-zero value  causes
              xdm  to  print  lots of debugging statements to the
              terminal; it also disables the  DisplayManager.dae-
              monMode resource, forcing xdm to run synchronously.
              To interpret these debugging messages,  a  copy  of
              the  source code for xdm is almost a necessity.  No
              attempt has been made to rationalize or standardize
              the output.

       -error error_log_file
              Specifies  the  value for the DisplayManager.error-
              LogFile resource.  This file contains  errors  from
              xdm  as  well  as anything written to stderr by the
              various  scripts  and  programs  run   during   the
              progress of the session.

       -resources resource_file
              Specifies    the    value   for   the   DisplayMan-
              ager*resources resource.  This file is loaded using
              xrdb  to  specify  configuration parameters for the
              authentication widget.

       -server server_entry
              Specifies the value for the  DisplayManager.servers
              resource.   See the section Local Server Specifica-
              tion for a description of this resource.

       -udpPort port_number
              Specifies the value for the DisplayManager.request-
              Port resource.  This sets the port-number which xdm
              will monitor for XDMCP requests.  As XDMCP uses the
              registered  well-known  UDP port 177, this resource
              should not be changed except for debugging.

       -session session_program
              Specifies the value for the  DisplayManager*session
              resource.  This indicates the program to run as the
              session after the user has logged in.

       -xrm resource_specification
              Allows an arbitrary resource to be specified, as in
              most X Toolkit applications.

RESOURCES
       At  many  stages  the  actions  of  xdm  can be controlled
       through the use of its configuration file, which is in the
       X  resource format.  Some resources modify the behavior of
       xdm on all displays, while others modify its behavior on a
       single  display.   Where actions relate to a specific dis-
       play, the display name is inserted into the resource  name
       between  ``DisplayManager''  and  the  final resource name
       segment.

       For local displays, the resource name  and  class  are  as
       read from the Xservers file.

       For remote displays, the resource name is what the network
       address of the display resolves to.  See the  removeDomain
       resource.   The  name must match exactly; xdm is not aware
       of all the network aliases that might reach a  given  dis-
       play.   If  the  name  resolve fails, the address is used.
       The resource class is as sent by the display in the  XDMCP
       Manage request.

       Because  the  resource manager uses colons to separate the
       name of the resource from its value and dots  to  separate
       resource  name parts, xdm substitutes underscores for both
       dots and colons when generating the  resource  name.   For
       example,  DisplayManager.expo_x_org_0.startup  is the name
       of the resource which defines the startup shell  file  for
       the ``expo.x.org:0'' display.

       DisplayManager.servers
              This  resource either specifies a file name full of
              server entries, one per line (if the  value  starts
              with  a  slash), or a single server entry.  See the
              section Local Server Specification for the details.

       DisplayManager.requestPort
              This  indicates  the UDP port number which xdm uses
              to listen for incoming XDMCP requests.  Unless  you
              need  to  debug  the  system,  leave  this with its
              default value of 177.

       DisplayManager.errorLogFile
              Error output is normally  directed  at  the  system
              console.   To  redirect  it, set this resource to a
              file name.  A method to send these messages to sys-
              log  should  be developed for systems which support
              it; however, the wide variety  of  interfaces  pre-
              cludes any system-independent implementation.  This
              file also contains any output directed to stderr by
              the Xsetup, Xstartup, Xsession and Xreset files, so
              it will contain descriptions of problems  in  those
              scripts as well.

       DisplayManager.debugLevel
              If  the  integer  value of this resource is greater
              than zero, reams of debugging information  will  be
              printed.  It also disables daemon mode, which would
              redirect the information into the  bit-bucket,  and
              allows  non-root users to run xdm, which would nor-
              mally not be useful.

       DisplayManager.daemonMode
              Normally, xdm attempts to make itself into a daemon
              process  unassociated  with  any terminal.  This is
              accomplished by forking and leaving the parent pro-
              cess  to  exit,  then  closing file descriptors and
              releasing the controlling terminal.  In some  envi-
              ronments  this  is not desired (in particular, when
              debugging).  Setting  this  resource  to  ``false''
              will disable this feature.

       DisplayManager.pidFile
              The  filename  specified will be created to contain
              an ASCII representation of the  process-id  of  the
              main  xdm  process.   Xdm also uses file locking on
              this file to attempt to eliminate multiple  daemons
              running  on  the  same  machine,  which would cause
              quite a bit of havoc.

       DisplayManager.lockPidFile
              This is the resource  which  controls  whether  xdm
              uses file locking to keep multiple display managers
              from running amok.  On  System  V,  this  uses  the
              lockf library call, while on BSD it uses flock.

       DisplayManager.authDir
              This  names  a  directory  under  which  xdm stores
              authorization files while initializing the session.
              The  default  value is <XRoot>/lib/X11/xdm.  Can be
              overridden for  specific  displays  by  DisplayMan-
              ager.DISPLAY.authFile.

       DisplayManager.autoRescan
              This  boolean controls whether xdm rescans the con-
              figuration, servers, access control and authentica-
              tion  keys files after a session terminates and the
              files have changed.  By  default  it  is  ``true.''
              You  can force xdm to reread these files by sending
              a SIGHUP to the main process.

       DisplayManager.removeDomainname
              When computing the display name for XDMCP  clients,
              the  name  resolver  will  typically create a fully
              qualified host name for the terminal.  As  this  is
              sometimes  confusing,  xdm  will  remove the domain
              name portion of the host name if it is the same  as
              the  domain  name of the local host when this vari-
              able is set.  By default the value is ``true.''

       DisplayManager.keyFile
              XDM-AUTHENTICATION-1  style  XDMCP   authentication
              requires  that  a private key be shared between xdm
              and the terminal.  This resource specifies the file
              containing  those  values.   Each entry in the file
              consists of a display name and the shared key.   By
              default,  xdm  does  not  include  support for XDM-
              AUTHENTICATION-1, as it requires DES which  is  not
              generally  distributable  because  of United States
              export restrictions.

       DisplayManager.accessFile
              To prevent unauthorized XDMCP service and to  allow
              forwarding  of  XDMCP  IndirectQuery requests, this
              file contains a database  of  hostnames  which  are
              either  allowed  direct  access to this machine, or
              have a list of hosts to  which  queries  should  be
              forwarded to.  The format of this file is described
              in the section XDMCP Access Control.

       DisplayManager.exportList
              A list of additional environment  variables,  sepa-
              rated  by  white  space,  to pass on to the Xsetup,
              Xstartup, Xsession, and Xreset programs.

       DisplayManager.randomFile
              A file to checksum to generate the seed  of  autho-
              rization  keys.  This should be a file that changes
              frequently.  The default is /dev/mem.

       DisplayManager.greeterLib
              On  systems  that  support  a  dynamically-loadable
              greeter  library, the name of the library.  Default
              is <XRoot>/lib/X11/xdm/libXdmGreet.so.

       DisplayManager.choiceTimeout
              Number of seconds to wait for  display  to  respond
              after  user  has  selected a host from the chooser.
              If the display sends an XDMCP IndirectQuery  within
              this  time,  the request is forwarded to the chosen
              host.  Otherwise, it is assumed to be  from  a  new
              session  and the chooser is offered again.  Default
              is 15.

       DisplayManager.sourceAddress
              Use the numeric IP address of the incoming  connec-
              tion  on multihomed hosts instead of the host name.
              This is to avoid trying to  connect  on  the  wrong
              interface which might be down at this time.

       DisplayManager.DISPLAY.resources
              This  resource specifies the name of the file to be
              loaded by xrdb as the resource  database  onto  the
              root window of screen 0 of the display.  The Xsetup
              program, the Login widget, and chooser will use the
              resources  set  in  this  file.  This resource data
              base is loaded just before the authentication  pro-
              cedure is started, so it can control the appearance
              of the login window.  See the  section  Authentica-
              tion  Widget, which describes the various resources
              that are appropriate to place in this file.   There
              is   no   default  value  for  this  resource,  but
              <XRoot>/lib/X11/xdm/Xresources is the  conventional
              name.

       DisplayManager.DISPLAY.chooser
              Specifies  the program run to offer a host menu for
              Indirect queries redirected  to  the  special  host
              name  CHOOSER.   <XRoot>/lib/X11/xdm/chooser is the
              default.  See the sections XDMCP Access Control and
              Chooser.

       DisplayManager.DISPLAY.xrdb
              Specifies  the  program used to load the resources.
              By default, xdm uses <XRoot>/bin/xrdb.

       DisplayManager.DISPLAY.cpp
              This specifies the name of the C preprocessor which
              is used by xrdb.

       DisplayManager.DISPLAY.setup
              This  specifies  a  program  which is run (as root)
              before offering the Login window.  This may be used
              to  change  the appearance of the screen around the
              Login window or to put up other windows (e.g.,  you
              may  want  to  run  xconsole here).  By default, no
              program is run.  The conventional name for  a  file
              used  here  is  Xsetup.  See the section Setup Pro-
              gram.

       DisplayManager.DISPLAY.startup
              This specifies a program which  is  run  (as  root)
              after  the  authentication  process  succeeds.   By
              default, no program is run.  The conventional  name
              for  a file used here is Xstartup.  See the section
              Startup Program.

       DisplayManager.DISPLAY.session
              This specifies the session to be executed (not run-
              ning  as  root).   By default, <XRoot>/bin/xterm is
              run.  The conventional name is Xsession.   See  the
              section Session Program.

       DisplayManager.DISPLAY.reset
              This  specifies  a  program  which is run (as root)
              after the session terminates.  By default, no  pro-
              gram is run.  The conventional name is Xreset.  See
              the section Reset Program.

       DisplayManager.DISPLAY.openDelay

       DisplayManager.DISPLAY.openRepeat

       DisplayManager.DISPLAY.openTimeout

       DisplayManager.DISPLAY.startAttempts
              These numeric resources control the behavior of xdm
              when   attempting  to  open  intransigent  servers.
              openDelay is the length of the pause  (in  seconds)
              between successive attempts, openRepeat is the num-
              ber of attempts to make, openTimeout is the  amount
              of  time to wait while actually attempting the open
              (i.e., the maximum time  spent  in  the  connect(2)
              system  call)  and  startAttempts  is the number of
              times this entire process is done before giving  up
              on the server.  After openRepeat attempts have been
              made, or if openTimeout seconds elapse in any  par-
              ticular  attempt,  xdm  terminates and restarts the
              server, attempting to connect again.  This  process
              is repeated startAttempts times, at which point the
              display is declared dead  and  disabled.   Although
              this  behavior  may  seem  arbitrary,  it  has been
              empirically developed and works quite well on  most
              systems.  The default values are 5 for openDelay, 5
              for openRepeat, 30 for openTimeout and 4 for  star-
              tAttempts.

       DisplayManager.DISPLAY.pingInterval

       DisplayManager.DISPLAY.pingTimeout
              To  discover  when  remote  displays disappear, xdm
              occasionally pings them, using an X connection  and
              XSync  calls.   pingInterval specifies the time (in
              minutes) between  each  ping  attempt,  pingTimeout
              specifies  the  maximum amount of time (in minutes)
              to wait for the terminal to respond to the request.
              If  the  terminal  does not respond, the session is
              declared dead and terminated.  By default, both are
              set  to  5 minutes.  If you frequently use X termi-
              nals which can become isolated  from  the  managing
              host,  you  may  wish  to increase this value.  The
              only worry is that sessions will continue to  exist
              after  the terminal has been accidentally disabled.
              xdm will not  ping  local  displays.   Although  it
              would  seem  harmless,  it  is  unpleasant when the
              workstation session is terminated as  a  result  of
              the server hanging for NFS service and not respond-
              ing to the ping.

       DisplayManager.DISPLAY.terminateServer
              This  boolean  resource  specifies  whether  the  X
              server  should  be terminated when a session termi-
              nates (instead of resetting it).  This  option  can
              be used when the server tends to grow without bound
              over time, in order to limit the amount of time the
              server is run.  The default value is ``false.''

       DisplayManager.DISPLAY.userPath
              Xdm sets the PATH environment variable for the ses-
              sion to this value.  It should be a colon separated
              list  of directories; see sh(1) for a full descrip-
              tion.    ``:/bin:/usr/bin:/usr/X11R6/bin:/usr/ucb''
              is  a  common  setting.   The  default value can be
              specified at build time in the X system  configura-
              tion file with DefaultUserPath.
       
	DisplayManager.DISPLAY.systemPath
              Xdm  sets  the  PATH  environment  variable for the
              startup and reset scripts  to  the  value  of  this
              resource.   The default for this resource is speci-
              fied at build time by the  DefaultSystemPath  entry
              in      the      system     configuration     file;
              ``/etc:/bin:/usr/bin:/usr/X11R6/bin:/usr/ucb'' is a
              common choice.  Note the absence of ``.'' from this
              entry.  This is a good practice to follow for root;
              it  avoids many common Trojan Horse system penetra-
              tion schemes.

       DisplayManager.DISPLAY.systemShell
              Xdm sets the SHELL  environment  variable  for  the
              startup  and  reset  scripts  to  the value of this
              resource.  It is /bin/sh by default.

       DisplayManager.DISPLAY.failsafeClient
              If the default session fails to execute,  xdm  will
              fall  back  to  this program.  This program is exe-
              cuted with no arguments,  but  executes  using  the
              same  environment  variables  as  the session would
              have had (see the  section  Session  Program).   By
              default, <XRoot>/bin/xterm is used.

       DisplayManager.DISPLAY.grabServer

       DisplayManager.DISPLAY.grabTimeout
              To  improve security, xdm grabs the server and key-
              board while reading the login  name  and  password.
              The  grabServer  resource  specifies  if the server
              should be held for the duration of  the  name/pass-
              word   reading.   When  ``false,''  the  server  is
              ungrabbed after the keyboard grab succeeds,  other-
              wise  the  server  is grabbed until just before the
              session begins.  The  default  is  ``false.''   The
              grabTimeout resource specifies the maximum time xdm
              will wait for the grab to succeed.   The  grab  may
              fail  if  some other client has the server grabbed,
              or possibly if the network latencies are very high.
              This resource has a default value of 3 seconds; you
              should be cautious when raising it, as a  user  can
              be  spoofed  by a look-alike window on the display.
              If the grab  fails,  xdm  kills  and  restarts  the
              server (if possible) and the session.

       DisplayManager.DISPLAY.authorize

       DisplayManager.DISPLAY.authName
              authorize  is  a  boolean  resource  which controls
              whether xdm generates and  uses  authorization  for
              the  local server connections.  If authorization is
              used, authName is a list  of  authorization  mecha-
              nisms to use, separated by white space.  XDMCP con-
              nections dynamically  specify  which  authorization
              mechanisms are supported, so authName is ignored in
              this case.  When authorize is set for a display and
              authorization   is   not  available,  the  user  is
              informed by having a different message displayed in
              the   login   widget.   By  default,  authorize  is
              ``true.''  authName is ``MIT-MAGIC-COOKIE-1,''  or,
              if      XDM-AUTHORIZATION-1      is      available,
              ``XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1.''

       DisplayManager.DISPLAY.authFile
              This file is used to communicate the  authorization
              data from xdm to the server, using the -auth server
              command line option.  It should be kept in a direc-
              tory which is not world-writable as it could easily
              be removed, disabling the  authorization  mechanism
              in  the server.  If not specified, a name is gener-
              ated from DisplayManager.authDir and  the  name  of
              the display.

       DisplayManager.DISPLAY.authComplain
              If  set to ``false,'' disables the use of the unse-
              cureGreeting in the login window.  See the  section
              Authentication Widget.  The default is ``true.''

       DisplayManager.DISPLAY.resetSignal
              The  number  of  the  signal xdm sends to reset the
              server.  See the section  Controlling  the  Server.
              The default is 1 (SIGHUP).

       DisplayManager.DISPLAY.termSignal
              The number of the signal xdm sends to terminate the
              server.  See the section  Controlling  the  Server.
              The default is 15 (SIGTERM).

       DisplayManager.DISPLAY.resetForAuth
              The original implementation of authorization in the
              sample server  reread  the  authorization  file  at
              server  reset  time,  instead  of when checking the
              initial connection.  As xdm  generates  the  autho-
              rization  information just before connecting to the
              display, an old server  would  not  get  up-to-date
              authorization  information.   This  resource causes
              xdm to send SIGHUP to the server after  setting  up
              the  file,  causing  an  additional server reset to
              occur, during  which  time  the  new  authorization
              information   will   be   read.    The  default  is
              ``false,'' which will work for all MIT servers.

       DisplayManager.DISPLAY.userAuthDir
              When xdm is unable  to  write  to  the  usual  user
              authorization  file ($HOME/.Xauthority), it creates
              a unique file name in this directory and points the
              environment  variable  XAUTHORITY  at  the  created
              file.  It uses /tmp by default.

CONFIGURATION FILE
       First, the xdm configuration file should be set up.   Make
       a  directory  (usually  <XRoot>/lib/X11/xdm, where <XRoot>
       refers to the root of the X11 install tree) to contain all
       of  the  relevant  files.  In the examples that follow, we
       use /usr/X11R6 as the value of <XRoot>.

       Here is a reasonable configuration file,  which  could  be
       named xdm-config:

            DisplayManager.servers:            /usr/X11R6/lib/X11/xdm/Xservers
            DisplayManager.errorLogFile:       /usr/X11R6/lib/X11/xdm/xdm-errors            DisplayManager*resources:          /usr/X11R6/lib/X11/xdm/Xresources            DisplayManager*startup:            /usr/X11R6/lib/X11/xdm/Xstartup
            DisplayManager*session:            /usr/X11R6/lib/X11/xdm/Xsession
            DisplayManager.pidFile:            /usr/X11R6/lib/X11/xdm/xdm-pid
            DisplayManager._0.authorize:       true
            DisplayManager*authorize:          false

       Note  that  this  file mostly contains references to other
       files.  Note also that some of the resources are specified
       with ``*'' separating the components.  These resources can
       be made unique for each different  display,  by  replacing
       the  ``*'' with the display-name, but normally this is not
       very useful.  See the Resources  section  for  a  complete
       discussion.

XDMCP ACCESS CONTROL
       The  database file specified by the DisplayManager.access-
       File provides information which xdm uses to control access
       from  displays  requesting  XDMCP service.  This file con-
       tains three types of entries:  entries which  control  the
       response  to  Direct  and Broadcast queries, entries which
       control the response to Indirect queries, and macro  defi-
       nitions.

       The  format of the Direct entries is simple, either a host
       name or a pattern, which is distinguished from a host name
       by  the  inclusion  of  one  or  more meta characters (`*'
       matches any sequence of 0  or  more  characters,  and  `?'
       matches  any  single character) which are compared against
       the host name of the display device.  If the  entry  is  a
       host   name,   all  comparisons  are  done  using  network
       addresses, so any name which converts to the correct  net-
       work  address  may  be used.  For patterns, only canonical
       host names are used in the comparison, so ensure that  you
       do  not attempt to match aliases.  Preceding either a host
       name or a pattern with a `!' character causes hosts  which
       match that entry to be excluded.

       To  only  respond to Direct queries for a host or pattern,
       it can be followed by the  optional  ``NOBROADCAST''  key-
       word.   This  can  be  used  to prevent an xdm server from
       appearing on menus based on Broadcast queries.

       An Indirect entry also contains a host  name  or  pattern,
       but  follows  it  with  a  list of host names or macros to
       which indirect queries should be sent.

      A macro definition contains a macro name  and  a  list  of
       host names and other macros that the macro expands to.  To
       distinguish macros from hostnames, macro names start  with
       a `%' character.  Macros may be nested.

       Indirect  entries may also specify to have xdm run chooser
       to offer a menu of hosts to connect to.  See  the  section
       Chooser.

       When  checking  access for a particular display host, each
       entry is scanned in turn  and  the  first  matching  entry
       determines the response.  Direct and Broadcast entries are
       ignored when scanning for  an  Indirect  entry  and  vice-
       versa.

       Blank  lines  are  ignored,  `#'  is  treated as a comment
       delimiter causing the rest of that line to be ignored, and
       `\newline'  causes  the  newline  to  be ignored, allowing
       indirect host lists to span multiple lines.

       Here is an example Xaccess file:

       #
       # Xaccess - XDMCP access control file
       #

       #
       # Direct/Broadcast query entries
       #

       !xtra.lcs.mit.edu   # disallow direct/broadcast service for xtra
       bambi.ogi.edu       # allow access from this particular display
       *.lcs.mit.edu       # allow access from any display in LCS

       *.deshaw.com        NOBROADCAST         # allow only direct access
       *.gw.com                                # allow direct and broadcast

       #
       # Indirect query entries
       #

       %HOSTS              expo.lcs.mit.edu xenon.lcs.mit.edu \
                           excess.lcs.mit.edu kanga.lcs.mit.edu

       extract.lcs.mit.edu xenon.lcs.mit.edu   #force extract to contact xenon
       !xtra.lcs.mit.edu   dummy               #disallow indirect access
       *.lcs.mit.edu       %HOSTS              #all others get to choose

CHOOSER
       For X terminals that do not offer a host menu for use with
       Broadcast  or Indirect queries, the chooser program can do
       this for them.  In the Xaccess file,  specify  ``CHOOSER''
       as  the  first  entry  in the Indirect host list.  Chooser
       will send a Query request to each of  the  remaining  host
       names  in  the list and offer a menu of all the hosts that
       respond.

       The list may consist of the word ``BROADCAST,''  in  which
       case chooser will send a Broadcast instead, again offering
       a menu of all hosts that respond.  Note that on some oper-
       ating  systems,  UDP  packets cannot be broadcast, so this
       feature will not work.

       Example Xaccess file using chooser:

       extract.lcs.mit.edu CHOOSER %HOSTS      #offer a menu of these hosts
       xtra.lcs.mit.edu    CHOOSER BROADCAST   #offer a menu of all hosts

       The program to use for chooser is specified  by  the  Dis-
       playManager.DISPLAY.chooser  resource.  For more flexibil-
       ity at this step, the chooser could  be  a  shell  script.
       Chooser  is the session manager here; it is run instead of
      a child xdm to manage the display.

       Resources for this program can be put into the file  named
       by DisplayManager.DISPLAY.resources.

       When the user selects a host, chooser prints the host cho-
       sen, which is read by the  parent  xdm,  and  exits.   xdm
       closes  its  connection  to  the  X server, and the server
       resets and sends  another  Indirect  XDMCP  request.   xdm
       remembers  the  user's  choice (for DisplayManager.choice-
       Timeout seconds) and forwards the request  to  the  chosen
       host, which starts a session on that display.

       When the user selects a host, chooser prints the host cho-
       sen, which is read by the  parent  xdm,  and  exits.   xdm
       closes  its  connection  to  the  X server, and the server
       resets and sends  another  Indirect  XDMCP  request.   xdm
       remembers  the  user's  choice (for DisplayManager.choice-
       Timeout seconds) and forwards the request  to  the  chosen
       host, which starts a session on that display.

LOCAL SERVER SPECIFICATION
       The  resource DisplayManager.servers gives a server speci-
       fication or, if the values starts with a  slash  (/),  the
       name  of  a file containing server specifications, one per
       line.

       Each specification indicates a display which  should  con-
       stantly  be  managed  and  which is not using XDMCP.  This
       method is used typically for local servers only.   If  the
       resource  or  the file named by the resource is empty, xdm
       will offer XDMCP service only.

       Each specification consists of at least  three  parts:   a
       display  name,  a  display class, a display type, and (for
       local servers) a command line to start the server.  A typ-
       ical entry for local display number 0 would be:

         :0 Digital-QV local /usr/X11R6/bin/X :0

       The display types are:

       local     local display: xdm must run the server
       foreign   remote display: xdm opens an X connection to a running server

       The  display  name must be something that can be passed in
       the -display option to an X program.  This string is  used
       to  generate  the  display-specific  resource names, so be
       careful to match the names (e.g., use ``:0  Sun-CG3  local
       /usr/X11R6/bin/X  :0''  instead  of  ``localhost:0 Sun-CG3
       local /usr/X11R6/bin/X :0'' if your  other  resources  are
       specified  as ``DisplayManager._0.session'').  The display
       class  portion  is  also  used  in  the   display-specific
       resources,  as  the class of the resource.  This is useful
       if you have a large collection of similar  displays  (such
       as  a  corral  of  X  terminals)  and  would  like  to set
       resources for groups of them.  When using XDMCP, the  dis-
       play is required to specify the display class, so the man-
       ual for your particular X  terminal  should  document  the
       display  class string for your device.  If it doesn't, you
       can run xdm in debug mode and look at the resource strings
       which it generates for that device, which will include the
       class string.

       When xdm starts a session, it sets up  authorization  data
       for  the  server.   For  local servers, xdm passes ``-auth
       filename'' on the server's command line to point it at its
       authorization  data.   For  XDMCP  servers, xdm passes the
       authorization data to the  server  via  the  Accept  XDMCP
       request.

RESOURCES FILE
       The  Xresources  file  is  loaded  onto  the  display as a
       resource database using xrdb.  As the authentication  wid-
       get  reads  this  database  before starting up, it usually
       contains parameters for that widget:

            xlogin*login.translations: #override\
                 Ctrl<Key>R: abort-display()\n\
                 <Key>F1: set-session-argument(failsafe) finish-field()\n\
                 <Key>Return: set-session-argument() finish-field()
            xlogin*borderWidth: 3
            xlogin*greeting: CLIENTHOST
            #ifdef COLOR
            xlogin*greetColor: CadetBlue
            xlogin*failColor: red
            #endif

       Please note the translations entry; it specifies a few new
       translations  for  the  widget which allow users to escape
       from the default session  (and  avoid  troubles  that  may
       occur  in  it).   Note that if #override is not specified,
       the default translations are removed and replaced  by  the
       new value, not a very useful result as some of the default
       translations are quite useful (such  as  ``<Key>:  insert-
       char ()'' which responds to normal typing).

       This file may also contain resources for the setup program
       and chooser.

SETUP PROGRAM
       The Xsetup file is run after  the  server  is  reset,  but
       before the Login window is offered.  The file is typically
       a shell script.  It is run as root, so should  be  careful
       about  security.   This  is  the  place to change the root
       background or bring up other windows that should appear on
       the screen along with the Login widget.

       In addition to any specified by DisplayManager.exportList,
       the following environment variables are passed:

            DISPLAY        the associated display name
            PATH           the value of DisplayManager.DISPLAY.systemPath
            SHELL          the value of DisplayManager.DISPLAY.systemShell
            XAUTHORITY     may be set to an authority file

       Note that since xdm grabs the keyboard, any other  windows
       will  not be able to receive keyboard input.  They will be
       able to interact with the mouse, however; beware of poten-
       tial security holes here.  If DisplayManager.DISPLAY.grab-
       Server is set, Xsetup will not be able to connect  to  the
       display  at  all.   Resources  for this program can be put
       into the file named by DisplayManager.DISPLAY.resources.

       Here is a sample Xsetup script:

            #!/bin/sh
            # Xsetup_0 - setup script for one workstation
            xcmsdb < /usr/X11R6/lib/monitors/alex.0
            xconsole -geometry 480x130-0-0 -notify -verbose -exitOnFail &

AUTHENTICATION WIDGET
       The authentication widget reads a name/password pair  from
       the  keyboard.   Nearly  every imaginable parameter can be
       controlled with a resource.   Resources  for  this  widget
       should  be  put into the file named by DisplayManager.DIS-
       PLAY.resources.  All of these have reasonable default val-
       ues, so it is not necessary to specify any of them.

       xlogin.Login.width,   xlogin.Login.height,
              xlogin.Login.x,  xlo- gin.Login.y
              The  geometry  of the Login widget is normally com-
              puted automatically.  If you wish  to  position  it
              elsewhere, specify each of these resources.

       xlogin.Login.foreground
              The color used to display the typed-in user name.

       xlogin.Login.font
              The font used to display the typed-in user name.

       xlogin.Login.greeting
              A string which identifies this window.  The default
              is ``X Window System.''

       xlogin.Login.unsecureGreeting
              When X authorization is requested in the configura-
              tion file for this display and none is in use, this
              greeting  replaces  the  standard  greeting.    The
              default is ``This is an unsecure session''

       xlogin.Login.greetFont
              The font used to display the greeting.

       xlogin.Login.greetColor
              The color used to display the greeting.

       xlogin.Login.namePrompt
              The  string  displayed  to  prompt for a user name.
              Xrdb strips trailing white space from resource val-
              ues,  so  to  add  spaces  at the end of the prompt
              (usually a nice thing),  add  spaces  escaped  with
              backslashes.  The default is ``Login:  ''

       xlogin.Login.passwdPrompt
              The string displayed to prompt for a password.  The
              default is ``Password:  ''

       xlogin.Login.promptFont
              The font used to display both prompts.

       xlogin.Login.promptColor
              The color used to display both prompts.

       xlogin.Login.fail
              A message which is displayed when  the  authentica-
              tion fails.  The default is ``Login incorrect''

       xlogin.Login.failFont
              The font used to display the failure message.

       xlogin.Login.failColor
              The color used to display the failure message.

       xlogin.Login.failTimeout
              The  number  of seconds that the failure message is
              displayed.  The default is 30.

       xlogin.Login.translations
              This specifies the translations used for the  login
              widget.  Refer to the X Toolkit documentation for a
              complete discussion on translations.   The  default
              translation table is:

                   Ctrl<Key>H:    delete-previous-character() \n\
                   Ctrl<Key>D:    delete-character() \n\
                   Ctrl<Key>B:    move-backward-character() \n\
                   Ctrl<Key>F:    move-forward-character() \n\
                   Ctrl<Key>A:    move-to-begining() \n\
                   Ctrl<Key>E:    move-to-end() \n\
                   Ctrl<Key>K:    erase-to-end-of-line() \n\
                   Ctrl<Key>U:    erase-line() \n\
                   Ctrl<Key>X:    erase-line() \n\
                   Ctrl<Key>C:    restart-session() \n\
                   Ctrl<Key>\\:   abort-session() \n\
                   <Key>BackSpace:delete-previous-character() \n\
                   <Key>Delete:   delete-previous-character() \n\
                   <Key>Return:   finish-field() \n\
                   <Key>:         insert-char() \

       xlogin.Login.allowNullPasswd
              If  set  to  ``true'',  allow  an otherwise failing
              password match to succeed if the account  does  not
              require   a   password  at  all.   The  default  is
              ``false'',  so  only  users  that  have   passwords
              assigned can log in.

       The actions which are supported by the widget are:

       delete-previous-character
              Erases the character before the cursor.

       delete-character
              Erases the character after the cursor.

       move-backward-character
              Moves the cursor backward.

       move-forward-character
              Moves the cursor forward.
       move-to-begining
              (Apologies  about  the  spelling error.)  Moves the
              cursor to the beginning of the editable text.

       move-to-end
              Moves the cursor to the end of the editable text.

       erase-to-end-of-line
              Erases all text after the cursor.

       erase-line
              Erases the entire text.

       finish-field
              If the cursor is in the name field, proceeds to the
              password  field;  if  the cursor is in the password
              field, checks the current name/password  pair.   If
              the  name/password  pair  is  valid, xdm starts the
              session.  Otherwise the  failure  message  is  dis-
              played and the user is prompted again.

       abort-session
              Terminates and restarts the server.

       abort-display
              Terminates  the  server, disabling it.  This action
              is not accessible  in  the  default  configuration.
              There  are  various reasons to stop xdm on a system
              console, such as when  shutting  the  system  down,
              when  using  xdmshell,  to  start  another  type of
              server, or to generally access the console.   Send-
              ing xdm a SIGHUP will restart the display.  See the
              section Controlling XDM.

       restart-session
              Resets the X server and starts a new session.  This
              can  be  used  when the resources have been changed
              and you want to test them or when  the  screen  has
              been overwritten with system messages.

       insert-char
              Inserts the character typed.

       set-session-argument
              Specifies a single word argument which is passed to
              the session at startup.  See  the  section  Session
              Program.

       allow-all-access
              Disables access control in the server.  This can be
              used when the .Xauthority file cannot be created by
              xdm.   Be very careful using this; it might be bet-
              ter to disconnect  the  machine  from  the  network
              before doing this.

STARTUP PROGRAM
       The Xstartup program is run as root when the user logs in.
       It is typically a shell script.  Since it is run as  root,
       Xstartup  should  be very careful about security.  This is
       the place to put commands which add entries  to  /etc/utmp
       (the  sessreg  program  may  be useful here), mount users'
       home directories from file servers, or abort  the  session
       if logins are not allowed.

       In addition to any specified by DisplayManager.exportList,
       the following environment variables are passed:

            DISPLAY        the associated display name
            HOME           the initial working directory of the user
            LOGNAME        the user name
            USER           the user name
            PATH           the value of DisplayManager.DISPLAY.systemPath
            SHELL          the value of DisplayManager.DISPLAY.systemShell
            XAUTHORITY     may be set to an authority file

       No arguments are passed to the script.   Xdm  waits  until
       this  script  exits  before starting the user session.  If
       the exit value of this script is non-zero, xdm  discontin-
       ues the session and starts another authentication cycle.

       The  sample  Xstartup file shown here prevents login while
       the file /etc/nologin exists.  Thus this is not a complete
       example, but simply a demonstration of the available func-
       tionality.

       Here is a sample Xstartup script:

            #!/bin/sh
            #
            # Xstartup
            #
            # This program is run as root after the user is verified
            #
            if [ -f /etc/nologin ]; then
                 xmessage -file /etc/nologin -timeout 30 -center
                 exit 1
            fi
            sessreg -a -l $DISPLAY -x /usr/X11R6/lib/xdm/Xservers $LOGNAME
            /usr/X11R6/lib/xdm/GiveConsole
            exit 0

SESSION PROGRAM
       The Xsession program is the command which is  run  as  the
       user's  session.   It  is  run with the permissions of the
       authorized user.

       In addition to any specified by DisplayManager.exportList,
       the following environment variables are passed:

            DISPLAY        the associated display name
            HOME           the initial working directory of the user
            LOGNAME        the user name
            USER           the user name
            PATH           the value of DisplayManager.DISPLAY.userPath
            SHELL          the user's default shell (from getpwnam)
            XAUTHORITY     may be set to a non-standard authority file
            KRB5CCNAME     may be set to a Kerberos credentials cache name

       At most installations, Xsession should look in $HOME for a
       file .xsession, which contains  commands  that  each  user
       would  like  to  use  as  a session.  Xsession should also
       implement a system default session  if  no  user-specified
       session exists.  See the section Typical Usage.

       An argument may be passed to this program from the authen-
       tication widget using the  `set-session-argument'  action.
       This  can  be  used to select different styles of session.
       One good use of this feature  is  to  allow  the  user  to
       escape  from  the  ordinary  session  when it fails.  This
       allows users to repair their own .xsession  if  it  fails,
       without  requiring administrative intervention.  The exam-
       ple following demonstrates this feature.

       This example recognizes  the  special  ``failsafe''  mode,
       specified  in  the translations in the Xresources file, to
       provide an escape from  the  ordinary  session.   It  also
       requires that the .xsession file be executable so we don't
       have to guess what shell it wants to use.

            #!/bin/sh
            #
            # Xsession
            #
            # This is the program that is run as the client
            # for the display manager.

            case $# in
            1)
                 case $1 in
                 failsafe)
                      exec xterm -geometry 80x24-0-0
                      ;;
                 esac
            esac

            startup=$HOME/.xsession
            resources=$HOME/.Xresources

            if [ -f "$startup" ]; then
                 exec "$startup"
            else
                 if [ -f "$resources" ]; then
                      xrdb -load "$resources"
                 fi
                 twm &
                 xman -geometry +10-10 &
                 exec xterm -geometry 80x24+10+10 -ls
            fi

       The user's .xsession file might look something  like  this
       example.   Don't  forget  that  the file must have execute
       permission.
            #! /bin/csh
            # no -f in the previous line so .cshrc gets run to set $PATH
            twm &
            xrdb -merge "$HOME/.Xresources"
            emacs -geometry +0+50 &
            xbiff -geometry -430+5 &
            xterm -geometry -0+50 -ls

RESET PROGRAM
       Symmetrical with Xstartup, the Xreset script is run  after
       the  user  session has terminated.  Run as root, it should
       contain commands that undo  the  effects  of  commands  in
       Xstartup,  removing  entries  from /etc/utmp or unmounting
       directories from file servers.  The environment  variables
       that were passed to Xstartup are also passed to Xreset.

       A sample Xreset script:
            #!/bin/sh
            #
            # Xreset
            #
            # This program is run as root after the session ends
            #
            sessreg -d -l $DISPLAY -x /usr/X11R6/lib/xdm/Xservers $LOGNAME
            /usr/X11R6/lib/xdm/TakeConsole
            exit 0

CONTROLLING THE SERVER
       Xdm controls local servers using POSIX signals.  SIGHUP is
       expected to reset the server, closing all  client  connec-
       tions  and  performing  other  cleanup duties.  SIGTERM is
       expected to terminate the server.  If these signals do not
       perform  the  expected  actions, the resources DisplayMan-
       ager.DISPLAY.resetSignal and  DisplayManager.DISPLAY.term-
       Signal can specify alternate signals.

       To  control remote terminals not using XDMCP, xdm searches
       the window hierarchy on the display and uses the  protocol
       request  KillClient in an attempt to clean up the terminal
       for the next session.  This may not actually kill  all  of
       the clients, as only those which have created windows will
       be noticed.  XDMCP provides a more  sure  mechanism;  when
       xdm closes its initial connection, the session is over and
       the terminal is required to close all other connections.

CONTROLLING XDM
       Xdm responds to two signals:  SIGHUP  and  SIGTERM.   When
       sent  a  SIGHUP,  xdm  rereads the configuration file, the
       access control  file,  and  the  servers  file.   For  the
       servers  file,  it  notices  if entries have been added or
       removed.  If a new entry has been added, xdm starts a ses-
       sion  on  the associated display.  Entries which have been
       removed are disabled immediately, meaning that any session
       in  progress  will be terminated without notice and no new
       session will be started.

       When sent  a  SIGTERM,  xdm  terminates  all  sessions  in
       progress  and  exits.  This can be used when shutting down
       the system.

       Xdm attempts to mark its various sub-processes  for  ps(1)
       by  editing  the  command  line  argument  list  in place.
       Because xdm can't allocate additional space for this task,
       it  is  useful to start xdm with a reasonably long command
       line (using the full path name should  be  enough).   Each
       process which is servicing a display is marked -display.

ADDITIONAL LOCAL DISPLAYS
       To  add  an additional local display, add a line for it to
       the Xservers file.  (See the section Local Server Specifi-
       cation.)

       Examine   the  display-specific  resources  in  xdm-config
       (e.g., DisplayManager._0.authorize) and consider which  of
       them  should  be  copied for the new display.  The default
       xdm-config has all the appropriate lines for  displays  :0
       and :1.

OTHER POSSIBILITIES
       You  can  use xdm to run a single session at a time, using
       the 4.3 init options or other suitable daemon by  specify-
       ing the server on the command line:

            xdm -server ":0 SUN-3/60CG4 local /usr/X11R6/bin/X :0"

       Or,  you  might  have  a file server and a collection of X
       terminals.  The configuration for this is identical to the
       sample above, except the Xservers file would look like

            extol:0 VISUAL-19 foreign
            exalt:0 NCD-19 foreign
            explode:0 NCR-TOWERVIEW3000 foreign

       This  directs xdm to manage sessions on all three of these
       terminals.  See the section Controlling Xdm for a descrip-
       tion  of  using signals to enable and disable these termi-
       nals in a manner reminiscent of init(8).

LIMITATIONS
       One thing that xdm isn't very good at doing is  coexisting
       with other window systems.  To use multiple window systems
       on the same hardware, you'll probably be  more  interested
       in xinit.

FILES
       <XRoot>/lib/X11/xdm/xdm-config
                           the default configuration file

       $HOME/.Xauthority   user   authorization  file  where  xdm
                           stores keys for clients to read

       <XRoot>/lib/X11/xdm/chooser
                           the default chooser

       <XRoot>/bin/xrdb    the default resource database loader


       <XRoot>/bin/X       the default server

       <XRoot>/bin/xterm   the default session program and  fail-
                           safe client

       <XRoot>/lib/X11/xdm/A<display>-<suffix>
                           the  default  place  for authorization
                           files

       /tmp/K5C<display>   Kerberos credentials cache

       Note: <XRoot> refers to the root of the X11 install  tree.

SEE ALSO
       X(1),   xinit(1),   xauth(1),   Xsecurity(1),  sessreg(1),
       Xserver(1),
       X Display Manager Control Protocol

AUTHOR
       Keith Packard, MIT X Consortium

X Version 11               Release 6.3                          1

(END)

"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

XWUD(1)                                                   XWUD(1)

NAME
       xwud - image displayer for X

SYNOPSIS
       xwud [-in file] [-noclick] [-geometry geom] [-display dis-
       play] [-new] [-std <maptype>] [-raw]  [-vis  <vis-type-or-
       id>]  [-scale]  [-help]  [-rv] [-plane number] [-fg color]
       [-bg color]

DESCRIPTION
       Xwud is an X Window System image undumping utility.   Xwud
       allows  X users to display in a window an image saved in a
       specially formatted dump file, such as produced by xwd(1).

OPTIONS
       -bg color
               If  a bitmap image (or a single plane of an image)
               is displayed, this option can be used  to  specify
               the  color  to  display  for  the  "0" bits in the
               image.

       -display display
               This option allows you to specify  the  server  to
               connect to; see X(1).

       -fg color
               If  a bitmap image (or a single plane of an image)
               is displayed, this option can be used  to  specify
               the  color  to  display  for  the  "1" bits in the
               image.

       -geometry geom
               This option allows you to  specify  the  size  and
               position  of  the window.  Typically you will only
               want to specify the position,  and  let  the  size
               default to the actual size of the image.

       -help   Print  out  a  short  description of the allowable
               options.

       -in file
               This option allows the user to explicitly  specify
               the  input  file on the command line.  If no input
               file is given, the standard input is assumed.

       -new    This option forces creation of a new colormap  for
               displaying  the  image.  If the image characteris-
               tics happen to match those of  the  display,  this
               can get the image on the screen faster, but at the
               cost of using a new colormap (which on  most  dis-
               plays will cause other windows to go technicolor).

       -noclick
               Clicking any button in the window  will  terminate
               the  application, unless this option is specified.
               Termination can always be achieved by typing  'q',
               'Q', or ctrl-c.

       -plane number
               You  can select a single bit plane of the image to
               display with this  option.   Planes  are  numbered
               with  zero  being the least significant bit.  This
               option can be used to figure out  which  plane  to
               pass to xpr(1) for printing.

       -raw    This  option forces the image to be displayed with
               whatever color values happen to currently exist on
               the  screen.   This  option  is mostly useful when
               undumping an image back onto the same screen  that
               the image originally came from, while the original
               windows are still on the screen,  and  results  in
               getting the image on the screen faster.

       -rv     If  a bitmap image (or a single plane of an image)
               is displayed, this option  forces  the  foreground
               and  background colors to be swapped.  This may be
               needed when displaying a bitmap  image  which  has
               the  color  sense  of  pixel  values  "0"  and "1"
               reversed from what they are on your display.

       -scale  Allow the window to  be  resized,  and  scale  the
               image to the size of the window.

       -std maptype
               This option causes the image to be displayed using
               the specified  Standard  Colormap.   The  property
               name  is  obtained by converting the type to upper
               case, prepending  "RGB_",  and  appending  "_MAP".
               Typical  types  are "best", "default", and "gray".
               See xstdcmap(1) for one way of  creating  Standard
               Colormaps.

       -vis vis-type-or-id
               This  option  allows  you  to specify a particular
               visual or visual class.  The default  is  to  pick
               the  "best" one.  A particular class can be speci-
               fied:  "StaticGray",  "GrayScale",  "StaticColor",
               "PseudoColor",  "DirectColor", or "TrueColor".  Or
               "Match" can be specified,  meaning  use  the  same
               class  as  the  source  image.   Alternatively, an
               exact visual id (specific to the  server)  can  be
               specified,  either  as  a hexadecimal number (pre-
               fixed with "0x") or as a decimal number.  Finally,
               "default"  can  be  specified,  meaning to use the
               same class as the colormap  of  the  root  window.
               Case is not significant in any of these strings.

ENVIRONMENT
       DISPLAY To get default display.

FILES
       XWDFile.h
               X Window Dump File format definition file.

BUGS
       xwud  doesn't  handle big/deep images very well on servers
       that don't have the BIG-REQUESTS extension.
SEE ALSO
       xwd(1), xpr(1), xstdcmap(1), X(1)

AUTHOR
       Bob Scheifler, MIT X Consortium

X Version 11               Release 6.3                          1

(END)


"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

SSH2(1)                        SSH2                       SSH2(1)

NAME
       ssh2 - secure shell client (remote login program)

SYNOPSIS
       ssh2 [-l login_name] hostname [command]

       ssh2  [-l login_name]  [-n]  [+a] [-a] [+x] [-x] [-i file]
       [-F file]  [-t]  [-v]  [-d debug_level]  [-V]  [-q]   [-f]
       [-e char]      [-c cipher]     [-p port]     [-P]     [-S]
       [-L port:host:hostport] [-R port:host:hostport] [+C]  [-C]
       [-o `option'] [-h] hostname [command]

DESCRIPTION
       Ssh2 (Secure Shell) is a program for logging into a remote
       machine and executing commands in a remote machine.  It is
       intended  to  replace  rlogin  and rsh, and provide secure
       encrypted communications between two untrusted hosts  over
       an insecure network.  X11 connections and arbitrary TCP/IP
       ports can also be forwarded over the secure channel.

       Ssh2 connects and logs into the specified  hostname.   The
       user  must  prove his identity to the remote machine using
       some authentication method.

       Public key authentication is based on the use  of  digital
       signatures.  Each user creates a public / private key pair
       for authentication purposes. The server knows  the  public
       key,  and  only  the user knows the private key. The file-
       names of private keys that are used in authentication  are
       set in $HOME/.ssh2/identification.  When the user tries to
       authenticate himself, the server checks $HOME/.ssh2/autho-
       rization for filenames of matching public keys and sends a
       challenge to the user end. User is authenticated by  sign-
       ing  the  challenge  using  the private key. See the FILES
       section below for more information on  identification  and
       authorization files.

       Private  /  public  key pairs can be created with ssh-key-
       gen2(1).  See ssh-agent2(1) for information on how to  use
       public key authentication in conjunction with an authenti-
       cation agent.

       If other authentication methods fail, ssh2 prompts  for  a
       password.  Since  all  communications  are  encrypted, the
       password will not be available for eavesdroppers.

       When the user's identity has been accepted by the  server,
       the server either executes the given command, or logs into
       the machine and gives the  user  a  normal  shell  on  the
       remote machine.  All communication with the remote command
       or shell will be automatically encrypted.

       If no pseudo tty has been allocated, the session is trans-
       parent and can be used to reliably transfer binary data.

       The session terminates when the command or shell in on the
       remote machine exits and all X11  and  TCP/IP  connections
       have  been  closed.  The exit status of the remote program
       is returned as the exit status of ssh2.

       If the user is using X11 (the DISPLAY environment variable
       is  set),  the  connection to the X11 display is automati-
       cally forwarded to the remote side in such a way that  any
       X11  programs  started from the shell (or command) will go
       through the encrypted channel, and the connection  to  the
       real  X  server  will be made from the local machine.  The
       user should not manually set DISPLAY.  Forwarding  of  X11
       connections  can  be  configured on the command line or in
       configuration files.

       The DISPLAY value set by ssh2 will  point  to  the  server
       machine,  but  with  a  display  number greater than zero.
       This is normal, and happens because ssh2 creates a "proxy"
       X  server on the server machine for forwarding the connec-
       tions over the encrypted channel.

       Ssh2 will also automatically set up Xauthority data on the
       server machine.  For this purpose, it will generate a ran-
       dom authorization cookie, store it in  Xauthority  on  the
       server,  and  verify  that any forwarded connections carry
       this cookie and replace it by the  real  cookie  when  the
       connection  is  opened.  The real authentication cookie is
       never sent to the server machine (and no cookies are  sent
       in the plain).

       If  the user is using an authentication agent, the connec-
       tion to the agent is automatically forwarded to the remote
       side unless disabled on command line or in a configuration
       file.

       Forwarding of arbitrary TCP/IP connections over the secure
       channel  can  be  specified either on command line or in a
       configuration file.  TCP/IP forwarding  can  be  used  for
       secure  connections  to  electronic purses or going trough
       firewalls.

       Ssh2 automatically maintains and checks  a  database  con-
       taining  public  keys  of hosts. When logging on to a host
       for the first time, the host's public key is stored  to  a
       file  .ssh2/hostkey_PORTNUMBER_HOSTNAME.pub  in the user's
       home directory.  If a host's identification changes,  ssh2
       issues  warning  and  disables  password authentication to
       prevent a Trojan horse from getting the  user's  password.
       Another  purpose  of  this mechanism is to prevent man-in-
       the-middle attacks which could otherwise be used  to  cir-
       cumvent the encryption.

       Ssh2 has built-in support for SOCKS version 4 for travers-
       ing firewalls.  See ENVIRONMENT.

OPTIONS
       -l login_name
              Specifies the user for login to the remote machine.

       -n     Redirect  input  from  /dev/null,  ie.  don't  read
              stdin. This option can also  be  specified  in  the
              configuration file.

       +a     Enable authentication agent forwarding. (default)

       -a     Disable authentication agent forwarding.

       +x     Enable X11 connection forwarding. (default)

       -x     Disable X11 connection forwarding.

       -i file
              Spefifies  the identity file for public key authen-
              tication. This option can also be specified in  the
              configuration file.

       -F file
              Specifies an alternative configuration file to use.
              NOTE:  $HOME/.ssh2/ssh2_config   is   still   read,
              options  specified  here  will  be  in  addition to
              those.

       -t     For tty allocation, ie. allocate a tty  even  if  a
              command is given. This option can also be specified
              in the configuration file.

       -v     Enable  verbose  mode.  Display  verbose  debugging
              mssages.  Equal  to `-d 2'. This option can also be
              specified in the configuration file.

       -d debug_level
              Print  extensive  debug  information   to   stderr.
              debug_level is either a number, from 0 to 99, where
              99 specifies that all debug information  should  be
              displayed, or a comma-separated list of assignments
              "ModulePattern=debug_level".

       -V     Display version string.

       -q     Make ssh2 quiet, so that  it  doesn't  display  any
              warning messages. This option can also be specified
              in the configuration file.

       -f     Fork into  background  after  authentication.  This
              option  can  also be specified in the configuration
              file.

       -e char
              Set escape character. Use ``none'' to disable. This
              option  can  also be specified in the configuration
              file. (default; ~)

       -c cipher
              Select encryption algorithm.  Multiple  -c  options
              are  allowed and a single -c flag can have only one
              cipher. This option can also be  specified  in  the
              configuration file.

       -p port
              Port  to connect to on the remote host. This option
              can also be specified in the configuration file.

       -P     Don't use priviledged source port.  With  this  you
              cannot use rhosts or rsarhosts authentications, but
              it can be used to bypass some firewalls  that  dont
              allow priviledged source ports to pass. This option
              can also be specified in  the  configuration  file.
              (not yet implemented)

       -S     Don't  request  a session channel. This can be used
              with port-forwarding requests if a session  channel
              (and  tty) isn't needed, or the server doesn't give
              one.


       -L port:host:hostport
              Specifies that the given port on the local (client)
              host  is to be forwarded to the given host and port
              on the remote side.  This  works  by  allocating  a
              socket  to  be listened port on the local side, and
              whenever a connection is made  to  this  port,  the
              connection is forwarded over the secure channel and
              a connection is  made  to  host:hostport  from  the
              remote machine.  Port forwardings can also be spec-
              ified in the configuration  file.   Only  root  can
              forward privileged ports.

       -R port:host:hostport
              Specifies   that  the  given  port  on  the  remote
              (server) host is to be forwarded to the given  host
              and port on the local side.  This works by allocat-
              ing a socket to listen to port on the remote  side,
              and whenever a connection is made to this port, the
              connection is forwarded over  the  secure  channel,
              and  a connection is made to host:hostport from the
              local machine.  Privileged ports can  be  forwarded
              only when logging in as root on the remote machine.

       +C     Enable compression.

       -C     Disable compression. (default)

       -o 'option'
              Can be used to give options in the format  used  in
              the configuration files.  This is useful for speci-
              fying options for which there is no  separate  com-
              mand-line  flag.  The option has the same format as
              a line in the configuration  file.   Comment  lines
              are not currently accepted via this option.

       -h     Display short help on command-line options.

       CONFIGURATION FILES

       Ssh2 obtains configuration data from the following sources
       (in this order): system's global configuration file (typi-
       cally  /etc/ssh2/ssh2_config),  user's  configuration file
       ($HOME/.ssh2/ssh2_config) and command line  options.   For
       each parameter, the last obtained value will be effective.

       The configuration file has the following format:


              `expression:' denotes the start of a per-host  con-
              figuration  block,  where  `expression' is an arbi-
              trary string which distinguishes  this  block  from
              others.   `expression'   can   contain   wildcards.
              `expression' will be  compared  with  the  hostname
              obtained  from the command-line, and if it matches,
              the block will be evaluated.  Evaluation  stops  at
              the  next `expression:' statement. If more than one
              match is found, all will be evaluated and the  last
              obtained  values  for parameters will be effective.
              Note that `expression' doesn't have to  be  a  real
              hostname,  as  long  as the `expression' block con-
              tains a "Host" configuration parameter,  where  the
              real hostname to connect is defined.

              Empty lines and lines starting with '#' are ignored
              as comments.

              Otherwise a line is of the  format  "keyword  argu-
              ments".  Note  that it is possible to enclose argu-
              ments in quotes,  and  use  standard  C-convention.
              The  possible  keywords  and  their meanings are as
              follows (note  that  the  configuration  files  are

              `expression:' denotes the start of a per-host  con-
              figuration  block,  where  `expression' is an arbi-
              trary string which distinguishes  this  block  from
              others.   `expression'   can   contain   wildcards.
              `expression' will be  compared  with  the  hostname
              obtained  from the command-line, and if it matches,
              the block will be evaluated.  Evaluation  stops  at
              the  next `expression:' statement. If more than one
              match is found, all will be evaluated and the  last
              obtained  values  for parameters will be effective.
              Note that `expression' doesn't have to  be  a  real
              hostname,  as  long  as the `expression' block con-
              tains a "Host" configuration parameter,  where  the
              real hostname to connect is defined.

              Empty lines and lines starting with '#' are ignored
              as comments.

              Otherwise a line is of the  format  "keyword  argu-
              ments".  Note  that it is possible to enclose argu-
              ments in quotes,  and  use  standard  C-convention.
              The  possible  keywords  and  their meanings are as
              follows (note  that  the  configuration  files  are
              case-sensitive, but keywords are case-insensitive):

       Host   Specifies the real host  name  to  log  into.  With
              `expression'  above,  this  can  be used to specify
              nicnames or abbreviations for hosts.Default is  the
              name   given   on  the  command  line.  Numeric  IP
              addresses are also permitted (both on  the  command
              line and in HostName specifications).

       User   Specifies the user to log in as. This can be useful
              if you have a  different  user  name  in  different
              machines.  This  saves  the  trouble  of  having to
              remember to give the user name on the command line.

       ForwardAgent
              Specifies whether the connection to the authentica-
              tion agent (if any) will be forwarded to the remote
              machine. The argument must be "yes" or "no".

       ForwardX11
              Specifies whether X11 connections will be automati-
              cally redirected over the secure channel  and  DIS-
              PLAY set. The argument must be "yes" or "no".

       PasswordAuthentication
              Specifies  whether  to use password authentication.
              The argument must be "yes" or "no".

       RHostsAuthentication
              Specifies whether to try rhosts  based  authentica-
              tion.   Note that this declaration only affects the
              client side and has no effect whatsoever  on  secu-
              rity.   Disabling  rhosts authentication may reduce
              authentication time on slow connections when rhosts
              authentication  is  not  used.  Most servers do not
              permit  RhostsAuthentication  because  it  is   not
              secure (see RhostsRSAAuthentication).  The argument
              must be "yes" or "no".  (not yet implemented)

       RHostsPubKeyAuthentication
              Specifies whether to try rhosts  based  authentica-
              tion  with public key host authentication.  This is
              the primary authentication method for  most  sites.
              RHostsRSAAuthentication  is a synonym for this key-
              word, and it is defined for backwards compatibility
              with  ssh1.   The  argument  must be "yes" or "no".
              (not yet implemented)

       PubKeyAuthentication
              Specifies whether to try public key authentication.
              Public key authentication will only be attempted if
              the identity file exists or an authentication agent
              is  running.   RSAAuthentication  is  a synonym for
              this keyword and is defined for  backward  compati-
              bility  with  ssh1.   The argument must be "yes" or
              "no".

       Port   Specifies the port number to connect on the  remote
              host.  Default is 22.

       Ciphers
              Specifies  the  ciphers  to  use for encrypting the
              session. Currently, des, 3des, blowfish,  idea  and
              arcfour  are supported, of which des, 3des and arc-
              four are in all distributions. Multiple ciphers can
              be  specified  as  a comma-separated list.  Special
              values to this option are any  and  anycipher  that
              allows  either  any  available  cipher  or excludes
              nonencrypting cipher mode none but allows all  oth-
              ers.

       IdentityFile
             Specifies  the  name  of  the user's identification
              file.

       AuthorizationFile
              Specifies the  name  of  the  user's  authorization
              file.

       RandomSeedFile
              Specifies the name of the user's randomseed file.

       ForcePTTYAllocation
              For  tty  allocation.  Ie. allocate a tty even if a
              command is given. The argument  must  be  "yes"  or
              "no".  (not yet implemented)

       VerboseMode
              Verbose  mode.  Causes ssh2 to print debugging mes-
              sages about its progress. This is helpful in debug-
              ging  connection, authentication, and configuration
              problems.

       QuietMode
              Quiet mode. Causes all warnings and diagnostic mes-
              sages  to be suppressed. Only fatal errors are dis-
              played. The argument must be "yes" or "no".

       Compression
              Specifies whether to use compression. The  argument
              must be "yes" or "no".

       FallbackToRsh
              Specifies  that if connecting via ssh2 fails due to
              a connection refused error (there is no sshd2  lis-
              tening  on  the  remote host), rsh should automati-
              cally be used instead  (after  a  suitable  warning
              about the session being unencrypted).  The argument
              must be "yes" or "no".  (not yet implemented)

       KeepAlive
              Specifies whether the system should send  keepalive
              messages  to  the  other  side.   If they are sent,
              death of the connection or  crash  of  one  of  the
              machines  will  be properly noticed.  However, this
              means that connections will die  if  the  route  is
              down temporarily, and some people find it annoying.

              The default is "yes" (to send keepalives), and  the
              client  will notice if the network goes down or the
              remote host dies.  This is  important  in  scripts,
              and many users want it too.

              To  disable  keepalives, the value should be set to
              "no" in both the server and the  client  configura-
              tion files.  (not yet implemented)

       LocalForward
              Specifies  that  a TCP/IP port on the local machine
              be forwarded  over  the  secure  channel  to  given
              host:port  from the remote machine. Argument should
              be enclosed in double-quotes  ("").  Argumentformat
              is port:remotehost:remoteport .

       RemoteForward
              Specifies  that a TCP/IP port on the remote machine
              be forwarded  over  the  secure  channel  to  given
              host:port  from the local machine.  Argument should
              be enclosed in double-quotes  ("").  Argumentformat
              is port:remotehost:remoteport .

       UseRsh Specifies  that  rlogin/rsh  should be used.  It is
              possible that the host does not  support  the  ssh2
              protocol.   This  causes  ssh2  to immediately exec
              rsh.  All other options are  ignored  if  this  has
              been  specified.   The  argument  must  be "yes" or
              "no".  (not yet implemented)

       BatchMode
              If set to "yes", passphrase/password querying  will
              be  disabled.  This option is useful in scripts and
              other batch jobs where you have no user  to  supply
              the  password.  The argument must be "yes" or "no".
              (not yet implemented)

       StrictHostKeyChecking
              If this flag is set to "yes", ssh2  ssh2  will  not
              automatically  add host keys. This provides maximum
              protection against trojan horse  attacks.  However,
              it  can be somewhat annoying if you frequently con-
              nect on new hosts. If this is set to "no" then  new
              host  will automatically be added to the known host
              files. The host keys of known hosts will  be  veri-
              fied  automatically in both cases.  (not yet imple-
              mented)

       EscapeChar
              Sets the escape character (default: ~).  The escape
              character can also be set on the command line.  The
              argument should be a single character, '^' followed
              by  a letter, or "none" to disable the escape char-
              acter entirely (making the  connection  transparent
              for binary data).

       PasswordPrompt
              Sets  the  password prompt, that the user sees when
              connecting to a host. Variables '%U' and  '%H'  can
              be  used  to  give  the user's login name and host,
              respectively.

       GoBackground
              Requests ssh2 to go to background after authentica-
              tion is done and forwardings have been established.
              This is useful if ssh2 is going to  ask  for  pass-
              words  or passphrases, but the user wants it in the
              background. The argument must  be  "yes"  or  "no".
              (not yet implemented)

       UseNonPriviledgedPort
              Specifies whether to use priviledged port when con-
              necting to other end. The default is "no" if rhosts
              or rsarhosts authentications are enabled. The argu-
              ment must be "yes" or "no".  (not yet implemented)

       DontReadStdin
              Redirect  input  from  /dev/null,  ie.  don't  read
              stdin. The argument must be "yes" or "no".

       Ssh1Compatibility
              Specifies  whether  to use SSH1 compatibility code.
              With this option, ssh1 is executed when the  server
              supports  only SSH 1.x protocols. The argument must
              be "yes" or "no".

       Ssh1Path
              Specifies the path to ssh1 client,  which  is  exe-
              cuted  if  the  server supports only SSH 1.x proto-
              cols. The arguments for ssh2 are passed to the ssh1
              client.

       ENVIRONMENT

       Ssh2  will  normally  set  the following environment vari-
       ables:

       DISPLAY
              The DISPLAY variable indicates the location of  the
              X11  server.   It  is  automatically set by ssh2 to
              point to a value of  the  form  "hostname:n"  where
              hostname  indicates  the host where the shell runs,
              and n is an integer >= 1.  Ssh2 uses  this  special
              value  to  forward  X11 connections over the secure
              channel.  The user should normally not set  DISPLAY
              explicitly,  as that will render the X11 connection
              insecure (and will require  the  user  to  manually
              copy any required authorization cookies).

       HOME   Set to the path of the user's home directory.

       LOGNAME
              Synonym  for  USER; set for compatibility with sys-
              tems using this variable.

       MAIL   Set to point the user's mailbox.

       PATH   Set to the default PATH, as specified when  compil-
              ing  ssh2  or, on some systems, /etc/environment or
              /etc/default/login.

       SSH_SOCKS_SERVER
              If SOCKS is used, it is configured with this  vari-
              able.   The format of the variable is socks://user-
              name@socks_server:port/network/netmask,network/net-
              mask  ...  for example by setting environment vari-
              able     SSH_SOCKS_SERVER     to      socks://mylo-
              gin@socks.ssh.fi:1080/203.123.0.0/16,198.74.23.0/24
              uses host socks.ssh.fi  port  1080  as  your  SOCKS
              server  if  connection is attempted outside of net-
              works 203.123.0.0 (16 bit domain)  and  198.74.23.0
              (8 bit domain) which are connected directly.

              A  default  value for SSH_SOCKS_SERVER variable can
              be specified at compile time by specifying  --with-
              socks-server=VALUE  on  the  configure command line
              when compiling ssh2.  The default value can be can-
              celled  by  setting  SSH_SOCKS_SERVER  to  an empty
              string, and overridden by setting  SSH_SOCKS_SERVER
              to  a  new  value.  If SSH_SOCKS_SERVER variable is
              set, it should almost always contain local loopback
              network  (127.0.0.0/8) as network that is connected
              directly.

       SSH2_AUTH_SOCK
              if exists, is used to indicate the path of a  unix-
              domain  socket used to communicate with the authen-
              tication agent (or its local representative).

       SSH2_CLIENT
              Identifies the client end of the  connection.   The
              variable  contains  three  space-separated  values:
              client ip-address, client port number,  and  server
              port number.

       SSH2_TTY
              This  is  set  to  the name of the tty (path to the
              device) associated with the current shell  or  com-
              mand.   If  the  current  session  has no tty, this
              variable is not set.

       TZ     The timezone variable is set to indicate  the  pre-
              sent  timezone  if  it  was set when the daemon was
              started (e.i. the daemon passes the  value  to  new
              connections).

       USER   Set to the name of the user logging in.

       Additionally,     ssh2    reads    /etc/environment    and
       $HOME/.ssh2/environment, and adds lines of the format VAR-
       NAME=value  to  the  environment.   Some  systems may have
       still additional mechanisms for setting  up  the  environ-
       ment, such as /etc/default/login on Solaris.

FILES
       $HOME/.ssh2/random_seed
              Used for seeding the random number generator.  This
              file  contains  sensitive  data   and   should   be
              read/write for the user and not accessible for oth-
              ers.  This file is created the first time the  pro-
              gram  is  run  and updated automatically.  The user
              should never need to read or modify this file.

       $HOME/.ssh2/ssh2_config
              This is the per-user configuration file.  The  for-
              mat  of this file is described above.  This file is
              used by the ssh2 client.  This file does  not  usu-
              ally  contain  any  sensitive  information, but the
              recommended  permissions  are  read/write  for  the
              user, and not accessible by others.

       $HOME/.ssh2/identification
              contains  information  on  how  the  user wishes to
              authenticate himself  when  contacting  a  specific
              host.

              The identification file has the same general syntax
              as the configuration files. Following keywords  may
              be used:

       IdKey  This  is  followed by the filename of a private key
              in the $HOME/.ssh2 directory used  for  identifica-
              tion  when  contacting  a  host.  If there are more
              than one IdKeys , they are tried in the order  that
              they appear in the identification file.

       $HOME/.ssh2/authorization
              contains  information on how the server will verify
              the identity of an user.

              The authorization file has the same general  syntax
              as  the configuration files. Following keywords may
              be used:

       Key    This is followed by the filename of a public key in
              the  $HOME/.ssh2 directory that is used for identi-
              fication when contacting the host.   If  there  are
              login.

       Command
              This keyword, if used, must follow  the  "Key"-key-
              word  above. This is used to specify a "forced com-
              mand", that will be executed  on  the  server  side
              instead of anything else when the user is authenti-
              cated. The command supplied by the user (if any) is
              put in the environment variable "SSH2_ORIGINAL_COM-
              MAND". The command is run on a pty if  the  connec-
              tion  requests a pty; otherwise it is run without a
              tty. A quote may be  included  in  the  command  by
              quoting  it  with a backslash. This option might be
              useful to restrict certain RSA keys to perform just
              a  specific  operation.  An  example might be a key
              that  permits  remote  backups  but  nothing  else.
              Notice  that  the  client may specify TCP/IP and/or
              X11 forwardings unless they are explicitly  prohib-
              ited.

AUTHORS
       SSH Communications Security Ltd.

       For more information, see http://www.ssh.fi.
 
SEE ALSO
       sshd2(8),   ssh-keygen2(1),   ssh-agent2(1),  ssh-add2(1),
       scp2(1), sftp(1) rlogin(1), rsh(1), telnet(1)

SSH2                      June 25, 1998                         1

(END)
           


""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
XAUTH(1)                                                 XAUTH(1)

NAME
       xauth - X authority file utility

SYNOPSIS
       xauth [ -f authfile ] [ -vqib ] [ command arg ... ]

DESCRIPTION
       The  xauth  program is used to edit and display the autho-
       rization information used in connecting to the  X  server.
       This  program  is  usually  used  to extract authorization
       records from one machine and merge them in on another  (as
       is the case when using remote logins or granting access to
       other users).  Commands (described below) may  be  entered
       interactively,  on  the xauth command line, or in scripts.
       Note that this program  does  not  contact  the  X  server
       except  when the generate command is used.  Normally xauth
       is not used to create the  authority  file  entry  in  the
       first place; xdm does that.

OPTIONS
       The following options may be used with xauth.  They may be
       given individually (e.g., -q -i) or  may  combined  (e.g.,
       -qi).

       -f authfile
               This  option  specifies  the name of the authority
               file to use.  By default, xauth will use the  file
               specified  by  the XAUTHORITY environment variable
               or .Xauthority in the user's home directory.

       -q      This option indicates that  xauth  should  operate
               quietly and not print unsolicited status messages.
               This is the default if  an  xauth  command  is  is
               given  on the command line or if the standard out-
               put is not directed to a terminal.

       -v      This option indicates that  xauth  should  operate
               results of  various  operations  (e.g.,  how  many
               records  have  been read in or written out).  This
               is the default if xauth is reading  commands  from
               its  standard  input  and  its  standard output is
               directed to a terminal.

       -i      This option indicates that xauth should ignore any
               authority file locks.  Normally, xauth will refuse
               to read or edit any authority files that have been
               locked  by  other programs (usually xdm or another
               xauth).

       -b      This option indicates that xauth should attempt to
               break  any authority file locks before proceeding.
               Use this option only to clean up stale locks.

COMMANDS
       The following commands may be used to manipulate authority
       files:

       add displayname protocolname hexkey
               An  authorization  entry for the indicated display
               using the given protocol and key data is added  to
               the  authorization file.  The data is specified as
               an even-lengthed  string  of  hexadecimal  digits,
               each pair representing one octet.  The first digit
               of each pair gives the most significant 4 bits  of
               the  octet, and the second digit of the pair gives
               the least significant 4 bits.  For example,  a  32
               character  hexkey would represent a 128-bit value.
               A protocol name consisting of just a single period
               is  treated  as  an  abbreviation  for  MIT-MAGIC-
               COOKIE-1.

       generate displayname protocolname [trusted|untrusted]
               [timeout seconds] [group group-id] [data hexdata]

               This command is similar to add.  The main  differ-
               ence is that instead of requiring the user to sup-
               ply the key data, it connects to the server speci-
               fied  in  displayname and uses the SECURITY exten-
               sion in order to get the key data to store in  the
               authorization  file.  If the server cannot be con-
               tacted or if it  does  not  support  the  SECURITY
               extension,   the  command  fails.   Otherwise,  an
               authorization  entry  for  the  indicated  display
               using  the  given  protocol is added to the autho-
               rization file.  A protocol name consisting of just
               a  single period is treated as an abbreviation for
               MIT-MAGIC-COOKIE-1.

               If the trusted option is used, clients  that  con-
               nect  using  this authorization will have full run
               of the display, as usual.  If untrusted  is  used,
               clients that connect using this authorization will
               be considered untrusted and prevented from  steal-
               ing  or  tampering  with data belonging to trusted
               clients.  See the SECURITY extension specification
               for  full  details  on the restrictions imposed on
               untrusted clients.  The default is untrusted.

               The timeout option specifies how long  in  seconds
               this  authorization  will be valid.  If the autho-
               rization remains unused (no clients are  connected
               with  it)  for  longer  than this time period, the
               server  purges  the  authorization,   and   future
               attempts to connect using it will fail.  Note that
               the purging done by the server does not delete the
               authorization  entry  from the authorization file.
               The default timeout is 60 seconds.

               The group option specifies the  application  group
               that  clients  connecting  with this authorization
               should  belong  to.   See  the  application  group
               extension  specification  for  more  details.  The
               default is to not belong to an application  group.

               The  data  option  specifies  data that the server
               should use to generate  the  authorization.   Note
               that  this  is not the same data that gets written
               to the authorization file.  The interpretation  of
               this  data  depends on the authorization protocol.
               The hexdata is in the same format  as  the  hexkey
               described  in  the add command.  The default is to
               send no data.

       [n]extract filename displayname...
               Authorization entries for each  of  the  specified
               displays  are  written  to the indicated file.  If
               the nextract command  is  used,  the  entries  are
               written  in  a  numeric  format  suitable for non-
               binary transmission  (such  as  secure  electronic
               mail).   The extracted entries can be read back in
               using the merge and nmerge commands.  If the file-
               name  consists  of just a single dash, the entries
               will be written to the standard output.

       [n]list [displayname...]
               Authorization entries for each  of  the  specified
               displays  (or  all  if  no displays are named) are
               printed on the standard output.  If the nlist com-
               mand is used, entries will be shown in the numeric
               format used by the  nextract  command;  otherwise,
               they  are  shown in a textual format.  Key data is
               always displayed in the hexadecimal  format  given
               in the description of the add command.

       [n]merge [filename...]
               Authorization  entries are read from the specified
               files  and  are  merged  into  the   authorization
               database,   superceding   any   matching  existing
               entries.  If  the  nmerge  command  is  used,  the
               numeric  format  given  in  the description of the
               extract command is used.  If a  filename  consists
               of  just a single dash, the standard input will be
               read if it hasn't been read before.

       remove displayname...
               Authorization entries matching the specified  dis-
               plays are removed from the authority file.

       source filename
               The specified file is treated as a script contain-
               ing xauth commands to execute.   Blank  lines  and
               lines beginning with a sharp sign (#) are ignored.
               A single dash may be used to indicate the standard
               input, if it hasn't already been read.

       info    Information  describing  the  authorization  file,
               whether or not any changes  have  been  made,  and
               from  where  xauth  commands  are  being  read  is
               printed on the standard output.

       exit    If any modifications have been made, the authority
               file  is written out (if allowed), and the program
               exits.  An end of file is treated as  an  implicit
               exit command.

       quit    The  program  exits,  ignoring  any modifications.
               This may also  be  accomplished  by  pressing  the
               interrupt character.

       help [string]
               A  description of all commands that begin with the
               given string (or all  commands  if  no  string  is
               given) is printed on the standard output.

       ?       A  short  list of the valid commands is printed on
               the standard output.

DISPLAY NAMES
       Display names for the add, [n]extract, [n]list,  [n]merge,
       and  remove  commands  use  the same format as the DISPLAY
       environment variable and the common -display command  line
       argument.    Display-specific  information  (such  as  the
       screen number) is unnecessary and will be ignored.   Same-
       machine  connections  (such  as local-host sockets, shared
       memory, and the Internet Protocol hostname localhost)  are
       referred  to  as hostname/unix:displaynumber so that local
       entries for  different  machines  may  be  stored  in  one
       authority file.

EXAMPLE
       The  most common use for xauth is to extract the entry for
       the current display, copy it to another machine, and merge
       it into the user's authority file on the remote machine:

               %  xauth extract - $DISPLAY | rsh otherhost xauth merge -

       The  following command contacts the server :0 to create an
       authorization  using  the   MIT-MAGIC-COOKIE-1   protocol.
       Clients  that  connect  with  this  authorization  will be
       untrusted.
            %  xauth generate :0 .

ENVIRONMENT
       This xauth program uses the  following  environment  vari-
       ables:

       XAUTHORITY
               to  get  the  name of the authority file to use if
               the -f option isn't used.

       HOME    to get the user's  home  directory  if  XAUTHORITY
               isn't defined.

FILES
       $HOME/.Xauthority
               default   authority   file   if  XAUTHORITY  isn't
               defined.

BUGS
       Users that have unsecure networks should take care to  use
       encrypted  file  transfer mechanisms to copy authorization
       entries  between  machines.   Similarly,  the   MIT-MAGIC-
       COOKIE-1  protocol is not very useful in unsecure environ-
       ments.  Sites that are interested in  additional  security
       may need to use encrypted authorization mechanisms such as
       Kerberos.

       Spaces are currently not allowed  in  the  protocol  name.
       Quoting could be added for the truly perverse.

AUTHOR
       Jim Fulton, MIT X Consortium

X Version 11               Release 6.3                          1

