GNOME Bugzilla – Bug 555464
xauth cookie errors when system hostname changes while gdm starts
Last modified: 2010-03-21 15:51:06 UTC
This bug appears since recent changes in NetworkManager, that modify the system hostname from localhost.localdomain to the "new" hostname of the machine depending on the DNS lookup of the IP address obtained from the dhcp lease, after network connection is established (the new hostname now resolves to 127.0.0.1, as /etc/hosts is updated accordingly by NM).
There's a race condition here :
1. NM starts and sets the default hostname to localhost.localdomain
2. gdm starts, and creates an xauth cookie with localhost.localdomain as hostname
3. NM obtains a dhcp lease, and changes system hostname to something else.
4. following attempts of gdm to connect to the X server fail with authentication errors
(details and logs in #554495)
dcbw suggests to not use system hostname as the xauth cookie in gdm.
So network manager shouldn't be changing the hostname at runtime. It's going to break all kinds of things.
We can just force "localhost" instead the auth cookie though.
Created attachment 144173 [details] [review]
Use localhost and XAUTHLOCALHOSTNAME env var
We have the same issue in openSUSE, and here's the solution we use: we use localhost as hostname (for local logins) and set XAUTHLOCALHOSTNAME to make sure it's always the one that gets used by X.
Hrm. XAUTHLOCALHOSTNAME is not upstream, it looks it's something specific to the openSUSE X packages. Sigh.
hmm we actually fixed this a while ago...
Are you still seeing the problem, Vincent, or is attachment 144173 [details] [review] obsolete?
Vincent, could you please comment on Rays question in comment #5? TIA!
This is still needed, but since XAUTHLOCALHOSTNAME is openSUSE-specific, I guess closing as NOTGNOME is probably the best thing to do...