gdm is explicitly configured to place .Xauthority files in $HOME. gdm refuses to do so -- apparently deliberately, because it thinks the home directory is on NFS. Instead, it places them in /tmp where tmpwatch deletes them. gdm has no business making this policy decision for me. If I happen to be using non-kerberized NFS, not AFS or any other file system where root-squashing is in effect, and happen to know that it's more insecure than the rest of the system, then I can edit the configuration. Since I know that anyone can append keys to my ~/.ssh/authorized_keys which is also on NFS, and happily become me on any box on the network, I choose not to edit the configuration to place my .Xauthority somewhere other than in $HOME. It's fine where it is. gdm shouldn't override its explicit configuration.
The tmpwatch thing is now fixed in upstream CVS by touching the file in /tmp every 12 hours. Also there is now an option to force gdm to place cookies in the home dir. The problem is not really being able to mount the directory and read the cookie, it is seeing it in transport. Thus while kerberos protects anyone from adding to your ~/.ssh/authorized_keys it doesn't protect it from being seen in transport, which is not a real problem, the ssh private key is encrypted and thus cannot be snooped. The MIT-MAGIC-COOKIE-1 is on the other hand not encrypted and thus would be broadcast over the network the moment you log in. So yes, if your NFS (or any other remote filesystem) setup allows anybody to mount your home directory, then obviously you are screwed security wise. However if you have authentication set up such that this is not possible, then you still do not wish to place the MIT-MAGIC-COOKIE-1 in your home dir as it will go over the network in the clear. Having authentication for mounting your home directory would be broken then since anyone could connect to your display and theoretically get access to your machine that way. Plus there is no real "explicit" configuration for the location, as UserAuthDir=~ is actually kind of a broken concept and won't work in older GDM versions anyway, the UserAuthDir config is really to specify a directory like /tmp or /var/tmp for all the auths (that was the point of the config option originally, I added ~ expansion because I was on crack at the time). Plus GDM is already anal about your home directory anyway. In any case upstream gdm will allow you to set security/NeverPlaceCookiesOnNFS=false and allow cookies on the network.
> Thus while kerberos protects anyone from addingto your ~/.ssh/authorized_keys > it doesn't protect it from being seen in transport, which is not a real > problem, the ssh private key is encrypted and thus cannot be snooped. OK... so if /tmp is on /dev/hda1 gdm will also check the permissions on /dev/hda1 and refuse to put the cookie there if it's world-readable? :) In fact isn't kerberized NFS generally used in conjunction with encryption of some form? Certainly it should be :) Thanks for the fix.
Sounds like this is resolved upstream. Thanks all.
gdm doesn't check the /tmp location really, yeah the paranoia has to stop somewhere I suppose :) I just assume that /tmp is on the machine itself. The idea is that /tmp has the right permissions (owned by root and sticky) for problems to not arise. I will make a new upstream release as soon as the greeter crash bug is resolved.