Cannot log in users if their Xauthority file is corrupt.

[Emmanuel Thomé]

Impact:
If a users X authority file contains invalid data the user will not be able to log in with LightDM until the file is corrected or removed. The reason for the corruption has not been identified.

To reproduce:
1. Stop lightdm
$ sudo stop lightdm
2. Create an invalid X authority file in the home directory of a user, e.g. from a text VT:
$ cp /etc/hostname ~/.Xauthority
3. Start lightdm
$ sudo start lightdm
4. Log into the user account in the greeter

Expected result:
Logged into graphical session.

Observed result:
Returned to greeter, graphical session not shown.

Regression potential:
Change is small and was a regression in 1.6 due to accidental removal line resetting the error variable after reading the existing X authority file. Seems unlikely to cause any side-effects.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lightdm - 1.7.18-0ubuntu1

---------------
lightdm (1.7.18-0ubuntu1) saucy; urgency=low

  * New upstream release:
    - Set session environment variables for guest sessions (1.7 regression).
      (LP: #1214504)
    - Don't fail writing X authority if reading it had an error. (LP: #1234400)
    - Update environment variables that we pass to Mir.
 -- Robert Ancell <email address hidden> Mon, 07 Oct 2013 11:57:02 +1300

[Emmanuel Thomé (emmanuel-thome)]

thanks.

Regarding lightdm itself, do you intend to also release a newer package for the 1.6 "stable" branch as well ? The current bug is in fact a 1.6 regression there as well (and this is how I noticed it). It's a bit counter-intuitive that the fix for a regression found in the "stable" branch is to be found an a package upgrade picked from the "unstable" branch... Unless you've just decided to EOL 1.6.

E.

[Robert Ancell (robert-ancell)]

This is already fixed in the 1.6 branch, and it is a good candidate for a SRU

[Brian Murray (brian-murray)]

Hello Emmanuel, or anyone else affected,

Accepted lightdm into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lightdm/1.6.0-0ubuntu4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Edwin Fine (emofine)]

This seems to happen every time I install a raring update or upgrade, but I haven't updated often enough to swear to this. I can tell you that I had this problem twice, which is exactly 2 times more than I should have.

Basically, I get the login greeter screen, type in my password, it goes away for a couple of seconds, and then returns to the greeter screen without any visible error message. This is a serious WTF moment.

I was able to work around it (after a *lot* of scratching around and looking in /var/log/lightdm/ and elsewhere, which really didn't help much, and online searches, which did, eventually), as follows.

In desperation, I created a new user using a console (Ctrl-Alt-F1) session and usermod (lucky for me, I know a bit of sysadmin stuff). It was able to log in with no problems, of course. After getting a clue that .Xauthority was the likely culprit, I simply copied the new user's .Xauthority file over the one in my home directory.

This is not necessarily the best way to do it (probably deleting the file and running 'xauth generate :0 . trusted' is), but that's what got me over the hump.

[Bruno Nova (brunonova)]

I've just faced this problem (removing .Xauthority solved it).

I've tested again with an invalid .Xauthority, and the login failed.
I then installed the proposed lightdm version (1.6.0-0ubuntu4) and restarted the service.
Tried to login again, and it seemed to work!

It's probably better for someone else to verify this.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lightdm - 1.6.0-0ubuntu4

---------------
lightdm (1.6.0-0ubuntu4) raring; urgency=low

  * debian/patches/09_corrupt_xauth.patch:
    - Handle corrupt X authority files correctly (LP: #1234400)
 -- Robert Ancell <email address hidden> Tue, 08 Oct 2013 14:27:05 +1300

[Scott Kitterman (kitterman)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Charles Jie (chjie)]

I've just experienced the same story as Mr. Bruno Nova (brunonova). I spent a whole day to shoot the trouble and identified that it's about .Xauthority.

I tracked the /var/log/lightdm/lightdm.log and looked into my .Xauthority. I found it contained two entries:

snow/unix:1 MIT-MAGIC-COOKIE-1 f8aa6a272ab2e68533175967a9e5d09d
snow.mydomain.com.tw/unix:0 MIT-MAGIC-COOKIE-1 1e9a7aeba63b74bef069a3629fe3e80a

Removing the 2nd entry, which should be 'snow' instead of 'snow.mydomain.com.tw', made my system recover and logs me in again.
(Usually I am the only user of this machine. The :1 entry is created when I successfully login with a new test account, and switch to login my normal account.)

I don't know when it was touched and by whom. I have tried to reconfigure postfix the other day. I have changed my /etc/hostname from snow to snow.mydomain.com.tw, but I changed it back later... I think short hostname is better for my administration.

Such condition rarely happens. It looks .Xauthority is seldom updated except necessity. However it(the greeter?) could be more robust for such cases.