Bug 106451
Summary: | gdm refuses to place .Xauthority where it's asked to. | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux Beta | Reporter: | David Woodhouse <dwmw2> |
Component: | gdm | Assignee: | Havoc Pennington <hp> |
Status: | CLOSED UPSTREAM | QA Contact: | Mike McLean <mikem> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | beta1 | CC: | 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
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. |