|
Bugzilla – Full Text Bug Listing |
| Summary: | gdm fails to start properly if hostname changes after X starts but before gdmslave connects to display | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | JP Rosevear <jpr> |
| Component: | GNOME | Assignee: | Hans Petter Jansson <hpj> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <nld10-bugs-qa> |
| Severity: | Major | ||
| Priority: | P1 - Urgent | CC: | ast, eich, fmfischer, michael.monreal |
| Version: | Factory | ||
| Target Milestone: | Beta 4 | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Failing log snippet
Successful gdm start message. gdm-xauthlocalhostname.patch |
||
|
Description
JP Rosevear
2008-08-25 14:53:05 UTC
I thought we had fixed such network issues (chaging IP adress resulted in no longer accessible DISPLAY) a long time ago. Could you please explain what gdmslave does exactly? BTW, pasting outputs with long lines results in unreadable comments. Better attach these. Thanks. HPJ can better explain the gdm stuff. Created attachment 235352 [details]
Failing log snippet
Created attachment 235353 [details]
Successful gdm start message.
Oops. The bug has been classified as GNOME bug. Re-add me to Cc later if you like. Submitted a fix for this - couldn't get XAUTHLOCALHOSTNAME stuff to work for me, so just made the cookie FamilyWild in the local case. With XAUTHLOCALHOSTNAME it appears like there is a race between cookie creation and exporting the environment variable. Egbert, sound right both for the fix and the race? For #6 Egbert: Ping. (In reply to comment #6 from JP Rosevear) > Submitted a fix for this - couldn't get XAUTHLOCALHOSTNAME stuff to work for > me, so just made the cookie FamilyWild in the local case. With > XAUTHLOCALHOSTNAME it appears like there is a race between cookie creation and > exporting the environment variable. Egbert, sound right both for the fix and > the race? > The host name in XAUTHLOCALHOSTNAME needs to be the same as the one written to the $XAUTHORITY file or $HOME/.Xauthority (if the environment variable isn't set). Whoever modifies the authority file should remember the hostname used there. Of course one needs to make sure that this variable is set in the environment the client is started in. The environment variable only needs to be set before the hostname changes. If for whatever reasons a client tries to connect after the cookie has been set and the hostname has change but before the environment variable is set, the client will fail to connect. I think here is what happens: gdm-slave is started immediately when the server is started as it is waiting for a SIGUSR1 which indicates that it can connect. While the Xserver is still starting up (and before it is able to send the SIGUSR1) the IP has changed. If gdm-slave had been started with XAUTHLOCALHOST set to exaclty the same value that had written to the authority file everything should have been fine. Can you a. log the value of XAUTLOCALHOST in gdm-slave and do a xauth list? Egbert, is it acceptable to just set "localhost" in both the cookie and the XAUTHLOCALHOSTNAME var? Created attachment 244153 [details]
gdm-xauthlocalhostname.patch
Here's a working patch that trades the old hack for just saving "localhost" into the xauth db and setting XAUTHLOCALHOSTNAME to "localhost" everywhere. The new gdm appears to be setting up environments in a number of places :/
If this looks good security-wise, I think it should go in. Since the problem is timing-related I'm not 100% positive that this fixes it, but it does look like it should. Gdm isn't saving the authority file in the user's home directory any more, right? Otherwise 'localhost' would be a bad idea as home directories could be shared over nfs, thus a second login would overwrite the credentials of the first. In the future we may want to switch to 'server interpreted' access control by default. It works like host based access control but is able to distinguish users. No more cookies are required. This has downsides of course and the security implications still need to be investigated. It uses /var/run/gdm/auth-for-$USER-$RANDOMSTRING/database, so I guess we're safe in that respect. Thanks a lot, Egbert! Submitted to GNOME:Factory. I just build an mbuild of the package submitted to stable and updated the gdm-files in an x86_64 installation. Afterwards opening yast and other applications failed after entering the root-password in the gnomesu-pop-up. Reverting to the old package fixes the problem. Looks like the check-in has a flaw? Tested this, and yes it fails, but remove the stale /root/.Xauthority manually and all should start working again. *** Bug 438161 has been marked as a duplicate of this bug. *** Also, make sure you have the updated libgnomesu package I submitted some time ago. Stephan, please re-open if you see this in b4. |