williams@marlin.cs.washington.edu (Stuart Williams) (03/27/91)
>>>>> On 27 Mar 91 10:44:18 GMT, andrew@resam.dk (Leif Andrew Rump) said: In article <1991Mar27.104418.3761@resam.dk> andrew@resam.dk (Leif Andrew Rump) writes: > I'm been using xhost for a long time and recently I realised that xhost + > is the same as "leaving your Porche in <main US city> with its motor on" > as one netter put it! He & other discussed xauth which sounded like the > answer to mine & a lot of others (sleep) problem - but what does it do? > ... Here is some tutorial documentation written about xauth. Another source is the 'ACCESS CONTROL' section of the X(1) man page. We use xdm, and june is the name of a machine. ----------------------------------------------------------------- Xauth: More Secure ------------------ Release 4 of X Version 11 provides a new authorization protocol which allows a more narrow restriction on what clients can use a display. It works as follows: in order for a client on a machine to access a display, it must know a particular key, called a "magic cookie", that the server has. When a client requests access it sends a "magic cookie" and if it matches one that the server has, access is allowed. Xdm initializes magic cookies in the server and also places them (by default) into the file $HOME/.Xauthority, which is readable only by the user. On the client's machine, the same "magic cookie" needs to exist in the $HOME/.Xauthority file so the client can send the appropriate key to the server to request access. There are several ways to make these keys match. The first is to have the files be identical. This is surely the case for clients running on the same machine as the server. So, local clients are given permission by default. Another example is if you are sitting in front of a workstation with two windows running xterms, one logged into the local workstation and the other logged into a remote workstation, and in both cases your home directory is automounted from the same machine, then the file $HOME/.Xauthority is the same to each machine, and a client on the remote workstation will be authorized to access the local workstation display. This is because it looks in the .Xauthority file to extract a key which matches the display name it is trying to access, and sends that to the server, which compares it with the key it knows about (in the same .Xauthority file) and it matches. The second way to have these files match is by sending the file to the remote machine. For example, after logging into a workstation you could execute the command "rcp .Xauthority june:" (assuming your .rhosts file on june is set up correctly) and then you could start clients on june accessing your local display. The third way to put this information in the file on june is to just send one entry from the local file and merge it into the remote file. To read the entry from the .Xauthorty file the command xauth(1) is used. For example, a csh command such as the following would allow your clients on june to access your local display: xauth extract - `hostname`:0 | rsh june xauth merge - where the "-" tells xauth extract to use stdout, and xauth merge to use stdin. The authorization protocol clearly is more specific about what clients can access a display than the xhost command is, but it is not entirely secure. MIT-MAGIC-COOKIE-1 is the only authorization protocol supplied with X, it is intended that it be replaced with a more secure version where higher security is desired. The use of the default protocol instead of a more secure one is due to restrictions on exporting the DES encryption algorithm from the U.S. Since the default protocol provides no encryption, the protocol is only as secure as the transport used to move authorization records from one machine to another, e.g. rsh, rcp, NFS, ftp, etc. Also note that the use of xhost overrides the security measures the authorization protocol attempts to provide. If xhost is used to allow clients access from a particular machine to a display, then no "magic cookie" is required of a client on that machine. This allows compatibility with previous releases of X.
andrew@resam.dk (Leif Andrew Rump) (03/27/91)
Hello World
I'm been using xhost for a long time and recently I realised that xhost +
is the same as "leaving your Porche in <main US city> with its motor on"
as one netter put it! He & other discussed xauth which sounded like the
answer to mine & a lot of others (sleep) problem - but what does it do?
I realised that my .Xauthority already contained a lot of information
about the servers I've been connected to:
cphxd3:0 MIT-MAGIC-COOKIE-1 05<lots and lots of nibbles>ac
cphxd3/unix:0 MIT-MAGIC-COOKIE-1 0<lots and lots of nibbles>ac
cphmlsk:0 MIT-MAGIC-COOKIE-1 5<lots and lots of nibbles>e1
cphmlsk/unix:0 MIT-MAGIC-COOKIE-1 5<lots and lots of nibbles>e1
...
I thought I was able to give permanent access to servers with xauth
but it seems like I've misunderstood something - what does it do? And
is it possible to give other users/server permanent permission to
open windows on my screen?
Leif Andrew
Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark
UUCP: andrew@ambra.dk, phone: +45 39 27 11 77 /
Currently at Scandinavian Airline Systems =======/
UUCP: andrew@resam.dk, phone: +45 32 32 51 54 \
SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark
If it's broke, fix it (The MS-DOS way)
If it aint broke, don't touch it (The Unix way)
If you can't fix it, fuck it (The U-boat way)