Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!ames!sheba.arc.nasa.gov!schoch
From: schoch@trident.arc.nasa.gov (Steve Schoch)
Newsgroups: comp.windows.x
Subject: Re: locking out users from a server....
Keywords: X11R4.18, SunOS, xinit  Dam* students anyway...
Message-ID: <1990Oct30.205926.28985@news.arc.nasa.gov>
Date: 30 Oct 90 20:59:26 GMT
References: <8974@ncar.ucar.edu>
Sender: usenet@news.arc.nasa.gov (USENET Administration)
Organization: NASA - Ames Research Center, Moffett Field, CA
Lines: 63

In article <8974@ncar.ucar.edu>, morreale@bierstadt.scd.ucar.edu (Peter Morreale) writes:
|> I'm trying to figger-out how I can lock my server against unauthorized
|> use on a *user* basis.  Locking out a host is easy, but can I
|> allow access from a specific logon on a host?  

When you get a list of host that are allowed to connect by running "xhost"
with no arguments, this shows you the list of hosts from which ANYBODY
can connect to your server.  xauth allows a client to connect to your
server whether it is listed in the xhost list or not.

For instance, I use xauth on my server.  When I type xhost, it show me this:

sheba 52% xhost
access control enabled (only the following hosts are allowed)
sheba 53%

In other words, NO hosts are allowed to connect to my server (without
X authorization).

|> X(1) and xauth(1) seem to imply that you can, however I see no provision
|> (in xauth) to allow say joe@foo.bar to connect to smith's server on
|> foobar.bar.

It doesn't work that way.  I assume you are using the R4 xdm.  Make sure
you have a line in xdm-config such as this:

DisplayManager*authFile:        /var/adm/xdm/auth-server

and make sure the directory exists where auth-server is supposed to go.

The way it works is this: (assuming it is using the MIT-MAGIC-COOKIE-1
authorization scheme)
	1.  xdm randomly generates a "magic cookie" (a 16-byte random number).

	2.  xdm puts this number in the "authFile" mentioned above.

	3.  It starts (or restarts) the server with the argument
"-auth /var/adm/xdm/auth-server".

	4.  X (the server) reads the magic cookie and then removes the file
(for security).

	5.  Using the magic cookie to authorize itself, xdm brings up the
login window.

	6.  When you login, xdm puts the magic cookie in a file called
".Xauthority" in your home directory.

	7.  Clients read this file and send the cookie to the server upon first
connecting.  If the cookie matches the one that was given to the server by
xdm, the connection is authorized whether the client is running on an
authorized host or not.

The xauth(1) program is used to read entries from the ".Xauthority" file.  Using
xauth, you can transfer a cookie to a remote machine with a command such as:

% xauth extract - $DISPLAY | rsh remote -l user xauth merge -

Or, you could use the "nextract" command to mail the cookie to another use who
could then bring up a window on your server.  The cookie is good until the
end of the session when xdm generates another cookie to give to the server.

	Steve