Bug 106451 - gdm refuses to place .Xauthority where it's asked to.
Summary: gdm refuses to place .Xauthority where it's asked to.
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: gdm
Version: beta1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-07 09:23 UTC by David Woodhouse
Modified: 2007-04-18 16:58 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2003-10-08 20:19:04 UTC

Attachments (Terms of Use)

Description David Woodhouse 2003-10-07 09:23:19 UTC
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.

Comment 1 George Lebl 2003-10-08 00:27:33 UTC
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

Comment 2 David Woodhouse 2003-10-08 07:44:11 UTC
>  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.

Comment 3 Havoc Pennington 2003-10-08 20:19:04 UTC
Sounds like this is resolved upstream. Thanks all.

Comment 4 George Lebl 2003-10-09 16:24:47 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.