In article <1994Apr8.125725.23355@bcarh54a.bnr.ca>, Greg Wesson wrote: >In article <2o1n8q$qsl@sbi.sbi.com> bet@std.sbi.com (Bennett Todd) writes: >>If you want to use send, it's worth your while to get xauth(1)-based >>authentication working. > >How does one go about doing that. I read the man page, but it really wasn't >much help. Is this something that the WGA has to do, or can I do it myself? You can do it yourself. What you need is some code in a script to kick off the X server. In general, you need to stuff a cookie into .Xauthority, then start up X with an argument telling it to use that file. I append after my sig a helpful note by Vivek Khera describing how to make this work. -Bennett bet@sbi.com From: khera@cs.duke.edu (Vivek Khera) Newsgroups: comp.lang.tcl Subject: Re: HELP: xauth? Message-ID: Date: 6 Oct 93 13:44:37 GMT Organization: Duke University CS Dept., Durham, NC >>>>> "SD" == Scott Deifik writes: SD> I've seen some stuff about xauth in this newsgroup tk3.3 but I SD> didn't get a chance to read it. I just can't seem to get send to SD> work (ie. I can't get xauth to work). How do you do it? I am SD> working on display scott:0.0 and I ran the command: xauth add SD> scott:0.0 . 00 I wasn't sure what the hex number shoud be, so I SD> just used "00". Here's my standard blurb on using xauth. This has nothing specifically to do with tcl or tk, so I've redirected followups to the appropriate newsgroup. By the way, using "xauth +" basically opens up your workstation to *everyone* on the network to which you are connected. If you are on the Internet, you really open up a can of worms... Author: Vivek Khera -*- text -*- Subject: making your X server more secure Originally Written: Tue, 10 Jul 90 12:26:15 -0400 Time-stamp: "August 10, 1993 12:28:31" Here's how I have made my X sessions more secure than just the xhost way. It is mostly transparent, and doesn't allow arbitrary users to plaster windows on my screen, or to snoop at my keyboard. Even people who log into the machine I'm working on can't connect to the server. This whole scheme is based on the MIT-MAGIC-COOKIE scheme, where each client must present to the server a magic cookie to prove that it is allowed to connect. The cookie is kept in a file in your home directory (.Xauthority) which only you are allowed to read. The server reads this file when it starts up, so if you change the cookie file, you will have to restart the server to make it read the new information. Normally you don't need to do this. The .Xauthority files can be merged using the xauth program. See the man page for some more details. Here is how to make yourself "secure": 1. Create a .xserverrc file similar to mine in your home directory. The important part is to pass the "-auth $HOME/.Xauthority" option to the X server on the last line. Here is what my .xserverrc file looks like: --cut here-- #!/bin/sh # for Xsun: # -ar1 NNN set keyboard repeat delay to NNN milliseconds # -ar2 NNN set keyboard repeat rate to NNN milliseconds if test -w /dev/cgthree0 -o -w /dev/cgsix0; then server=Xsun else server=XsunMono fi # we *must* do an exec for the server so that signals are handled properly exec $server -ar1 250 -ar2 20 -auth $HOME/.Xauthority --cut here-- 2. Before you start the X server, be sure to create the .Xauthority file. I wrote a shell script to do this, called newcookie. You must create a new .Xauthority file when you switch machines, as the name of the machine the server is on is part of the authority mechanism. This is how it knows which cookie to send to which server it is connecting to. I run newcookie from my .login file when I am logging into the console. If you run newcookie after you start the X server, you are hosed unless you can remember the random number it generated and recreate the .Xauthority file by hand; otherwise you will have to quit and restart the server. Here is my newcookie program. If you have a program that generates md5 signatures, you can use it to generate a strong random number by passing the -md5 flag. If you have md4, just edit the script to use it instead of md5. If you don't have md4 or md5, then it assumes you have perl to generate random numbers. If you don't have perl, then write your own program to generate a long random number with an even number of hexadecimal digits in it, and then run "xauth add" like in my program. Note that md4 and md5 generate values that an even number of digits long already. An implementation of md5 can be found in Internet RFC 1321. --cut here-- #!/bin/sh # create new .Xauthority file PATH=/usr/local/X/bin:/usr/gnu/bin:$PATH # try some security auth=$HOME/.Xauthority #cp /dev/null $auth # generate a nice long random key if [ "$1" = "-md5" ]; then # use a random noise source and get a strong checksum of it. # this is probably a stronger random number than the other method. key=`pstat -pfS | md5` else # quick and dirty. can probably be recreated if time can be guessed. key=`perl -e 'srand; printf int(rand(100000000000000000))'` # use $key$key to make sure even length. key=$key$key fi # add to auth file. xauth add ${HOST}/unix:0 . $key xauth add ${HOST}:0 . $key --cut here-- 3. Make sure any program you run does not do an xhost + command. This will destroy any security you might gain by using xauth. Notably, the rcmd script does this. 4. Start the X server using startx. Things should be secure now. All new X clients (from R4 and later) understand this authorization scheme, so you should never need to run xhost again. (Unless you are using the standard Ultrix libraries -- but then you get what you deserve.) In fact, xhost should report *no* hosts as being allowed in. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Gradual Student/Systems Guy Department of Computer Science Internet: khera@cs.duke.edu Box 90129 RIPEM/PGP/MIME spoken here Durham, NC 27708-0129 (919)660-6528 David Herron writes: Therefore the trick of putting .Xauthority in $HOME does not work. X clients on remote systems do not have the same $HOME/.Xauthority as on my workstation making things more difficult. Yes, X makes things more difficult, but we already knew that. :-) I'm in the same situation. My approach is to copy the authority information to each machine that needs it after I log in. If you can rsh without typing a password (via kerberos, .rhosts, or whatever) then the xauth manpage suggests the following: xauth extract - $DISPLAY | rsh other xauth merge - In other cases I do the rlogin and then paste the right stuff into the window to prime that machine for X. To make that easier, I first run the following program, which computes all the right stuff (DISPLAY, xauth, launch an xterm, and quit the rlogin session) and then puts it into the primary selection, and echos it, so I can easily paste or rsh its output. #!/bin/sh # authother -- print commands which prepare the other machine for X : ${HOST:=`hostname`} HOST=`nslookup $HOST | awk '/Name: / { print $2 }'` AUTH=`xauth list $HOST:0` || { echo "authother: cannot read xauth list $HOST:0" 1>&2; exit 1; } cmd=" DISPLAY=$HOST:0; xauth add $AUTH; xterm & exit " xselection -replace PRIMARY "$cmd" echo $cmd In article <1994Apr13.103145.12871@pyra.co.uk>, Jimmy Aitken wrote: > >This is fine and I can see how to do this if I start up an X session >directly. However, how do you do this if when you turn on your X terminal, >you get an xdm login prompt? Ay help would be gratefully received. My experience is with SGI machines (IRIX 4.0.x) but it probably applies generally. When you start a session under xdm it puts a cookie in your .Xauthority and a matching cookie in the X server for you. If its not doing this then you have to find the xdm-config file (on SGI machines its in /usr/lib/X11/xdm/xdm-config) and edit it to turn authorization on (it will be obvious and the xdm man page has more). Once this is done kill off the X server and xdm should start up a new session with authorization enabled. If anyone knows a more elegant way to reinitialize the server with authorization I'd love to know. You should also do 'xhost -'. I think xauth doesnt work if xhost access is enabled (which it is by default on IRIX 4.0.x). Good luck.