I'm having a problem getting AFS, SGI's version of xdm, and X Authority authentication all to co-exist peacefully, and I'm wondering if anyone else has tackled this problem. Some more detailed information follows. As many of you no doubt are aware, there are a couple of different ways of authenticating to an X windows session. At our site, we generally try to have everyone use the X Authority mechanism, since that is now supported by nearly all versions of X we use, and it offers much better security than the xhost(1) method. The X Authority mechanism has all the clients involved read the server password from a file. This file generally lives in $HOME/.Xauthority. However, due to a myriad of legacy apps and a few cranky machines that we cannot install an AFS login on, everyone's home directories are setup so system:anyuser can read them. This negates the security provided by X Authority, as anyone reading the file can connect to the person's X server. However, on our Sun systems, we have users define an XAUTHORITY environment variable to point to a X Authority file in a protected subdirectory, and users run a special .xserverrc from startx that points the X server to the same subdirectory, and that all works great (In other words, we do _not_ run xdm on our Suns). Now, we have some SGI systems as well. We want everyone on the SGI's to use X Authority as well (especially since the default setup on the SGI's is to xhost the entire universe!). But we're running into a conflict with the way xdm works. Xdm is X-Authority aware, which is cool. However, it is hardcoded to write the X Authority file into your home directory, which is not cool, especially since all of our home directories are readable by system:anyuser (see above). We've tried creating a symlink from $HOME/.Xauthority to the Xauthority file in a private directory. But it turns out that before xdm writes out a new .Xauthority file, it _unlinks_ the old one, which wipes out the symlink. So a symlink is right out. So I figured it would be easy enough to just compile a new version of xdm for the SGI. Well, it turns out that the SGI version of xdm isn't exactly a stock version of xdm - SGI has enhanced it in many different ways. Any versions of xdm I built for the SGI's from the R5 & R6 sources ended up just putting up a blank screen upon login. So I'm wondering if anyone else has tried solving this problem, and if so, what did they do? As I see it, I have two options: - Get a version of xdm working on the SGI. - Bypass all the graphical login stuff and force people to login on a glass tty and start X by hand like we do with the Suns. Any hints or suggestions would be most welcome. --Ken
