Bug 106451

Summary: gdm refuses to place .Xauthority where it's asked to.
Product: [Retired] Red Hat Linux Beta Reporter: David Woodhouse <dwmw2>
Component: gdmAssignee: Havoc Pennington <hp>
Status: CLOSED UPSTREAM QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: beta1CC: jirka
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-10-08 20:19:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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
network.

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.